We're currently chasing down some wireless issues which, at least in
some cases, manifest as the EAP-PEAP or EAP-TTLS conversation being
aborted in the middle; i.e. after a couple of successful back and
forths, Radiator sends an EAP Request in a RADIUS challenge, and we
never receive a subsequent RADIUS request with the corresponding EAP
Response. This is a wireless/client problem, not a Radiator problem,
but I'm hoping that Radiator can help me log how often it's occurring
and from where.
My problem is that since the RADIUS auth never actually completes, this
aborted-conversation scenario never generates an AuthLog entry. So far
I've identified it through limited tcpdump captures, using Wireshark to
manually follow the RADIUS/EAP conversation. No doubt I could also see
it if I enabled Radiator debug logging with trace 4, but I really don't
want to do that on my production systems (we have a lot of traffic, and
_most_ of it is successful).
In theory it looks to me like it ought to be possible to add code to
Radius::Context::handle_timeout to examine the state of
$Radius::Context::contexts{$id} before it gets destroyed, decide if the
context state indicates an aborted conversation, and if so generate a
log message.
In practice, I'm not sure what fields within the context would be best
to examine. It looks like checking for the absence of
'handshake_finished' => 1 might be a good first pass to catch many
problem cases, but not necessarily all of them.
Any advice/ideas?
Also, does this in general seem like a sane enough thing to do that
Radiator might consider putting a Hook here?
Thanks,
David
P.S. My situation is further complicated by the fact that I don't have
a good way to reproduce the lack-of-EAP-response condition on any
networks other than production (so I can't easily e.g. use Dumper to see
what the context actually ends up looking like in that case).
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
