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-... Sent from the FreeRadius - User mailing list archive at Nabble.com.