I'm very curious about the outcome of this as well. The AP is
*supposed* to block all traffic except for EAP traffic pending the
required EAP-Success from the Authentication Server. If the AP is
allowing non-EAP traffic through, and, given that the client->AP traffic
occurs unencrypted until the EAPoL Keys are sent, that could allow a
total bypass of security on those APs.
Ick. I hope this doesn't turn out to be true for any other vendors...
I'm pretty sure that it doesn't work that way for Proxim APs since I've
seen the EAPoL exchange hang on those guys before and the client gives
up and tries to communicate anyway to no avail...
--Mike
Alan DeKok wrote:
"Timothy J. Miller" <[EMAIL PROTECTED]> wrote:
However, the AP holds the authentication pending but *leaves the
client fully connected*. This means that as long as an incomplete
reauthentication is pending, a previously-authenticated client
remains online. Not the effect I was looking for.
That would appear to be a bug in the AP. I'd be curious to know how
many AP's have that bug. If so, it would be a very, very, serious
problem.
I'm not sure how to fix that, to be honest. There's little you can
do on the RADIUS server to make the AP work.
My only suggestion is to try another AP. If that works, mail Cisco,
and tell them about the bug.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
