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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
