Issue with EAP authentication on packet loss

Arran Cudbard-Bell a.cudbardb at freeradius.org
Wed Apr 25 10:55:12 CEST 2018



> On Apr 25, 2018, at 7:52 PM, jm+freeradiususer at roth.lu wrote:
> 
> Hello,
> 
> 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.
> 
> This is consistent with what we see in step #4 (upon sending the Access-Accept which gets lost), namely this:
> (1) eap : Expiring EAP session with state 0x2f8521a02f84259c
> (1) eap : Finished EAP session with state 0x2f8521a02f84259c
> (1) eap : Previous EAP request found for state 0x2f8521a02f84259c, released from the list
> 
> Who's at fault? How do you solve this (except for not using UDP)? Do you set aggressive timeouts/retries on the NAS?

Yeah you can do that.  What's happening are there are internal timers that cleanup the session information (keyed off the State attribute), so when that retransmission comes in the session has already been cleared out.

In v3.0.x the state tree cleanup time is main_config.max_request_time * 10.
In v4.0.x the state tree cleanup time is continuation_timeout which defaults to 15.

You should try and fix the underlying issue before going down the route of tweaking timers though.

-Arran


More information about the Freeradius-Users mailing list