On 04/10/12 16:45, Matthias Nagel wrote:
I cannot find any pattern, so I do not believe it to be a client side issue.
Of course, one can argue to ignore the warning as it works most of the time, but I do not like indeterministically behaving IT systems, hence it preys on my mind.
Has anybody an idea what the reason might be? If anybody wants to see a full debug output or a tcpdump, I can provide you with plenty of that. But I could not find anything.
One thing: that logging only happens in "debug" mode. Most people don't run in debug mode all the time, so as far as I know, it could be normal - maybe everyone sees failure rates of that order? Anyway, first things - check your "eap {}" module config, specifically ensure that max_sessions is high enough to support your load, that timer_expire isn't too low, and if applicable, that your TLS session caching is ok (size, particularly). Otherwise - I assume you are authenticating wireless clients? Unfortunately, wireless is funky. Clients can stop doing the EAP exchange for all sorts of reasons - interference / packet loss, signal strength issues (they moved to a different AP), prompting the user for password / cert issuance, etc. Are you able to determine where the EAP sessions have got to before they hang up? Are they still in TLS setup, or inner-tunnel? Does it hang up after e.g. the EAP-MSCHAP challenge? Regrettably the "session did not finish" logging isn't great, so determining this is hard - I keep meaning to see if it can be improved e.g. log some attributes from the original packet, log the state of the EAP session, etc.