On 4/25/2018 12:39 PM, Arran Cudbard-Bell wrote:
On Apr 25, 2018, at 8:45 PM, Stefan Winter <stefan.winter@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.