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. johannes - 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
