On Tuesday 14 November 2006 15:40, Johannes Berg wrote: > On Wed, 2006-11-15 at 01:29 +1100, Paul TBBle Hampson wrote: > > > Just to summarise results so far: > > > > (Current version) > > bcm43xx-d80211 w/v3 firmware and TKIP: Garbled broadcast RX > > bcm43xx-d80211 w/v4 firmware and TKIP: Garbled broadcast RX > > bcm43xx-d80211 w/v4 firmware and WEP-104: Correct broadcast RX > > > > (version from wireless-dev before October 23rd, unsure of exact date) > > bcm43xx (softmac) w/v3 firmware and TKIP: Correct broadcast RX > > The last item is interesting. The softmac version doesn't include any hw > crypto so it never checks the 'decrypt attempted' bit in the RX header > afaik, leaving all crypto to hw. > > I postulated before that the problem is that the firmware sets the > 'decrypt attempted' bit even if the key is none, hence the driver tells > the d80211 stack that the frame was already decrypted (no decrypt error > occurs because in reality the algorithm is 'none'.) > > You could test this theory by clearing the 'decrypt attempted' bit > unconditionally in the RX path before it is ever tested. Then, any > wep/aes should no longer work properly with v4 firmware and > bcm43xx-d80211, but tkip would. If my theory is correct.
yes, Johannes. The problem is that the decrypt attempted bit is even set for key_none. When I force-disable this codepath, TKIP works perfectly well. I will do a patch for this. There are a few other minor bugs in the crypto stuff, which I will fix, too. Key clearing is not handled 100% correct, etc... -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
