Bug 154237

Summary: [ath] AR9280 w/ AES-CCMP (WPA2) group key does not work
Product: Base System Reporter: Adrian Chadd <adrian>
Component: kernAssignee: Adrian Chadd <adrian>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Adrian Chadd freebsd_committer freebsd_triage 2011-01-23 11:40:11 UTC 
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.

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:
Comment 1 Adrian Chadd freebsd_committer freebsd_triage 2011-01-23 12:18:57 UTC 
bschmidt has reported that it breaks broadcast traffic in his
environment. He's seeing encrypted frames being passed verbatim back
to his station.

This needs to be fully tested with combinations of encryption type
(TKIP/AES-CCMP) and BSSID MAC.
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2011-01-26 11:07:24 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 3 Adrian Chadd freebsd_committer freebsd_triage 2011-01-27 06:46:47 UTC 
Responsible Changed
From-To: freebsd-net->adrian

My bug
Comment 4 Adrian Chadd freebsd_committer freebsd_triage 2011-04-09 04:03:40 UTC 
State Changed
From-To: open->closed

This bug has been fixed for a while; the keycache multicast key 
code was using the wrong bit in the ethernet address to signify 
what's going on.