EAP-TLS:Error: rlm_eap: Failed to store handler

[leopold]

Alan thank you very much for your explanation.

Just to confirm that the following scenario cannot cause the same problem:
Client sends Access-Request and the server responds with Access-Challenge
but the response never reaches the client. The client retransmits exact same
packet again and the server tries to remove the handler from the tree
(remove fails for some reason or session was not found in the tree at that
time) and then after it tries to process the packet it finds the handler in
the session tree even though it was supposed to be removed and prints this
error message.
We are suspecting network problems at the time of this error and suspect
that server responces never reached the client and client replayed the same
EAP message.
Thanks again


Alan DeKok-2 wrote:
> 
> leopold wrote:
>> We are using 2.1.4 version and sometimes we see the following error
>> Wed Sep 16 11:21:01 2009 : Error: rlm_eap: Failed to store handler
> 
>   That error means that the "current" EAP packet is *already* in the
> list of known EAP sessions.  So trying to insert it twice is bad.
> 
>> This error is very difficult to reproduce, but if the server goes into
>> this
>> mode it starts randomly rejecting some users and accepting others.
>> Many users get rejected with the same error message
>> The only way now is to restart server and then it works fine.
> 
>   That would be the recommended thing to do.
> 
>> Could there be some kind of rbtree corruption or there is a way to
>> explain
>> this when EAP session is already in the tree and client retries or for
>> some
>> reason sends message twice the server finds the session based on STATE
>> variable in the tree and prints this message?
> 
>   When the server receives an EAP packet, any old handler is *removed*
> from the list.  This is done with a mutex, so there should be no
> possibility for two packets to be processed simultaneously.  i.e. with a
> retransmit.
> 
>   I suspect that the problem is really some kind of memory corruption.
> But without knowng more, it's hard to say.
> 
>> This would be okay if one client gets rejected is supplicant misbehaves
>> and
>> sends duplicate requests, but many clients get the same failure.
>> Are there any code fixes from 2.1.4 and 2.1.7 that fix exact same
>> problem?
> 
>   No.  I don't even know what is causing the problem.
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> 
> 

-- 
View this message in context: http://www.nabble.com/EAP-TLS%3AError%3A-rlm_eap%3A-Failed-to-store-handler-tp25492256p25530392.html
Sent from the FreeRadius - User mailing list archive at Nabble.com.