Similar to the urtwn(4) WPA1/TKIP fix I have just committed, there's
a bug in athn(4) where the value of ni_rsncipher is used to guide the
hardware- vs. software-crypto decision for multicast frames, not just
for unicast frames as was intended.
This means multicast frames could fail to decrypt if the AP is configured
to use WPA1/TKIP instead of WPA2/CMMP as the group cipher (symptoms may
include dhclient failing to get link).
Ok?
diff 89be218cf39e3311509e6aba9a8efd44b360a42f /usr/src
blob - 560db09a447651b7bcabac7b94286a872b313ee2
file + sys/dev/ic/ar5008.c
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -1003,7 +1003,8 @@ ar5008_rx_process(struct athn_softc *sc, struct mbuf_l
(wh->i_fc[1] & IEEE80211_FC1_PROTECTED) &&
(ic->ic_flags & IEEE80211_F_RSNON) &&
(ni->ni_flags & IEEE80211_NODE_RXPROT) &&
- (ni->ni_rsncipher == IEEE80211_CIPHER_CCMP ||
+ ((!IEEE80211_IS_MULTICAST(wh->i_addr1) &&
+ ni->ni_rsncipher == IEEE80211_CIPHER_CCMP) ||
(IEEE80211_IS_MULTICAST(wh->i_addr1) &&
ni->ni_rsngroupcipher == IEEE80211_CIPHER_CCMP))) {
if (ar5008_ccmp_decap(sc, m, ni) != 0) {
