Quoting Johannes Berg <[EMAIL PROTECTED]>: >> > info->control.hw_key is NULL. >> >> Is a NULL pointer supposed to tell "do not encrypt", or is this a >> mac80211 bug? > > It's probably a bug.
I've bisected it to commit 57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99: mac80211: move TX info into skb->cb It turns out that commit introduces two sparse warnings in net/mac80211/wpa.c: net/mac80211/wpa.c:202:10: warning: incorrect type in return expression (different base types) net/mac80211/wpa.c:202:10: expected int net/mac80211/wpa.c:202:10: got restricted ieee80211_tx_result [usertype] <noident> net/mac80211/wpa.c:448:10: warning: incorrect type in return expression (different base types) net/mac80211/wpa.c:448:10: expected int net/mac80211/wpa.c:448:10: got restricted ieee80211_tx_result [usertype] <noident> That's returning TX_CONTINUE from tkip_encrypt_skb() and ccmp_encrypt_skb(), where an integer should be returned. Both times it happens after info->control.hw_key is set. The callers of those functions check for negative numbers only, but TX_CONTINUE is 0, and TX_DROP is 1. Something must be wrong there. wep_encrypt_skb() in wep.c would not return TX_CONTINUE. But most importantly, there is a suspicious change in wep_encrypt_skb() - the key is set in the other branch of the condition. I'll try to restore the original logic in wep.c. I'll post a patch if it works. -- Regards, Pavel Roskin _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
