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" <tmiller@mitre.org> 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