Hello,
Am Donnerstag 04 Oktober 2012, 17:09:35 schrieb Phil Mayers:
> 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.
> >
> > 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?
That would be nice, indeed. But if the reason is signal strengh of a WiFi, then
the numbers heavily depend on your WiFi coverage. So it is difficult to compare.
> 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).
I did not find "max_sessions" anywhere in the config files. Where is it
supposed to be set and what is the default if not set? "timer_expire" is 60
seconds. The cache size for session resumption is set to 0. I read that this
means "infinite" somewhere. I see a lot of session resumptions that work.
I found the entry
# fragment_size = 1024
to be commented out. Does anybody has experiences with HP E-MSM 430 APs?
Probably, this is a dummy question: I always believed that the smallest MTU
that must be supported by an ethernet devices is 1500. Are there really APs
that support less? I did not find anything on that in the specifications of my
AP. And second question: Does a wrong value for fragment_size always fail? Or
to state it conversely: If a default fragment size of 1024 works most of the
time (as it does with me), can this still be a reason for the failure, if it is
too high?
> Otherwise - I assume you are authenticating wireless clients?
Half-half. It is a HP 5412 chassis solution with an integrated MSM 765zl WiFi
controller. Most clients are wired (desktop pcs) and some clients (Smartphones,
Tablets, Laptops) are wireless. But yes, if I (hopefully correctly) link the
error message to the corresponding access challenge, most errors are from
wireless sessions.
> 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?
I am not sure, if I do the linking between error message and access challenge
correctly. But if I do so, there is no particular point.
> 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.
At the moment I do the following: I pick the hex number from the error message
and look for an access challenge, that has the same number in its "State" AVP.
If this is the wrong way to do, then all I said before is non-sense.
Matthias
----------------------------------------------------------------------
Matthias Nagel
Willy-Andreas-Allee 1, Zimmer 506
76131 Karlsruhe
Telefon: +49-721-8695-1506
Mobil: +49-151-15998774
e-Mail: matthias.h.na...@gmail.com
ICQ: 499797758
Skype: nagmat84
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
