TKIP failures and turning off access point

[Jeremy C. Reed]

I had a problem a couple months ago where my system would bring
down the entire wireless network. I was told my system was trying
(repeatedly) to authenticate which the AP took as an attack. The
response to that attack was "knock everyone off the AP and sleep
for X seconds".  The fix was to turn off the stuff on the access
point that was killing everyone. I don't know if the following
problem is related.

I was told:

-=-=-=-=-=-=
We use WPA/WPA2 wireless authentication.  I'm not familiar with all of
the details, but the basic premise is that you use a pre-shared key (the
wireless "password") to generate a session key.  Session keys are valid
for specific timeperiods and/or byte counts.  When that time period or
byte count is exceeded, your wireless card and the AP must roll over to
a new key.

The key exchange is done via a protocol called TKIP.  What the router
was saying was that the TKIP packet from your host was invalid.  I am
unsure if your client was initiating the roll over, or if this was in
response to the AP requesting roll over.  In any event, the AP decided
your TKIP response was corrupt.

Cisco's default, which we were using, is that 2 or more TKIP failures in
60 seconds means the AP is being "attacked", and the AP attempts to
protect itself.  It does so by turning off it's radio completely, thus
disconnecting all the other users on the AP.

Someone could DDOS the wireless by intentionally generating TKIP
errors; so rather than allow that I reconfigured the AP's to not
down the radio interface.  TKIP errors are still logged, but they
will not cause others to be disconnected.
-=-=-=-=-=-=

I was using: wpa_supplicant v0.4.9 on NetBSD 4.0.

Does anyone know about this?

Is this related to my other email?