On Wed, 2007-08-15 at 08:16 -0500, Larry Finger wrote: > > Thing is, it looks as though all frames that trigger the message are > > dropped, and I'm fairly certain we don't actually want that. Looks like I was right. This is really strange, and it plays into the RX key selection that Volker also complained about. I've tested this with my network, which is using CCMP for pairwise and TKIP for group keys, and I started getting the same message as you had but with "CCMP failed" instead of "TKIP failed". Adding all the addresses to the debug output got me: CCMP decrypt failed for RX frame from 00:15:f2:3d:63:97 to 33:33:00:00:00:02 Note how it's sending to that IPv6 multicast address but trying to decrypt with CCMP although I have TKIP GTK keys. And as expected, I see *no* multicast traffic on wlan0. The problem obviously is key selection: if (rx->sta && rx->sta->key) use rx->sta->key well, duh, that's obviously wrong since we have a pairwise (sta) key for the AP, but it's sending us a multicast frame. I've been thinking about revamping key selection, I guess this is something to really look into now... Anyhow, this confirms that the patch is wrong, it suppresses messages that we failed to decrypt frames that we should be seeing, in this case multicast and broadcast frames. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
