From owner-freebsd-bugs@FreeBSD.ORG Sun Jan 23 11:40:12 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D03F1065673 for ; Sun, 23 Jan 2011 11:40:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E4C818FC1A for ; Sun, 23 Jan 2011 11:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0NBeB22037877 for ; Sun, 23 Jan 2011 11:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0NBeBWI037876; Sun, 23 Jan 2011 11:40:11 GMT (envelope-from gnats) Resent-Date: Sun, 23 Jan 2011 11:40:11 GMT Resent-Message-Id: <201101231140.p0NBeBWI037876@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Adrian Chadd Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ECF1106564A for ; Sun, 23 Jan 2011 11:38:55 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (unknown [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 7E26B8FC15 for ; Sun, 23 Jan 2011 11:38:55 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p0NBctHP036551 for ; Sun, 23 Jan 2011 11:38:55 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p0NBctnq036550; Sun, 23 Jan 2011 11:38:55 GMT (envelope-from nobody) Message-Id: <201101231138.p0NBctnq036550@red.freebsd.org> Date: Sun, 23 Jan 2011 11:38:55 GMT From: Adrian Chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/154237: [ath] AR9280 w/ AES-CCMP (WPA2) group key does not work X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 11:40:12 -0000 >Number: 154237 >Category: kern >Synopsis: [ath] AR9280 w/ AES-CCMP (WPA2) group key does not work >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 23 11:40:11 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: HEAD r217687 >Organization: >Environment: FreeBSD i386 >Description: Associating to my local TP-Link WN-1043ND running OpenWRT works, but no traffic is passed. Turning on the keycache debugging (athdebug +keycache) shows that the group keys are being installed in slots 1+2 (alternating for each group rekey), with the unicast key in slot 4. Associating to the AP in WPA1 mode w/ TKIP as the group key shows no issue. One important part - the MAC of the device is 94:0c:6d:fe:4f:20; notice the high bit of the MAC address is set. This is apparently a sign to the keycache that the key is a multicast key. Just as a side-note; Working AES-CCMP WPA/WPA2 is required for 802.11n. >How-To-Repeat: >Fix: If an AES group key is not installed in the shared key space (key 0->3), the problem goes away. I'm not sure whether AR_KEYTABLE_VALID in the keycache entry is supposed to be involved here or not. I need to do some further digging. This seems to fix it: Index: if_ath.c =================================================================== --- if_ath.c (revision 217719) +++ if_ath.c (working copy) @@ -2223,6 +2223,11 @@ { struct ath_softc *sc = vap->iv_ic->ic_ifp->if_softc; + /* Station mode? Don't use the group keys for AES/CCMP */ + if (vap->iv_opmode == IEEE80211_M_STA && sc->sc_mcastkey && k->wk_cipher->ic_cipher == IEEE80211_CIPHER_AES_CCM) { + return key_alloc_single(sc, keyix, rxkeyix); + } + /* * Group key allocation must be handled specially for * parts that do not support multicast key cache search >Release-Note: >Audit-Trail: >Unformatted: