From nobody@FreeBSD.org  Thu Jan 20 02:18:55 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id CE6F81065674
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 20 Jan 2011 02:18: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 BE5728FC08
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 20 Jan 2011 02:18: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 p0K2ItkU031753
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 20 Jan 2011 02:18:55 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p0K2ItIm031752;
	Thu, 20 Jan 2011 02:18:55 GMT
	(envelope-from nobody)
Message-Id: <201101200218.p0K2ItIm031752@red.freebsd.org>
Date: Thu, 20 Jan 2011 02:18:55 GMT
From: Adrian Chadd <adrian@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: AR5213 + MIPS + WPA group key packet corruption
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         154153
>Category:       kern
>Synopsis:       [ath] AR5213 + MIPS + WPA group key packet corruption
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-wireless
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 20 02:20:09 UTC 2011
>Closed-Date:    
>Last-Modified:  Sat Apr 09 03:07:44 UTC 2011
>Originator:     Adrian Chadd
>Release:        9.0-CURRENT
>Organization:
FreeBSD
>Environment:
Any recent HEAD is fine. These tests have been done with r214406 (21 Oct 2010) but the HAL and net80211 layer hasn't changed since then. The problem exists with the latest HEAD.
>Description:
Clients can associate to an 11g interface but can't pass broadcast/multicast traffic.

It's related to broadcast traffic.

* Broadcast DHCP traffic from the laptop -> AP works
* AP sends DHCP request
* AP receives a DHCP reply, broadcast
* AP sends DHCP reply to the client
* client never receives reply

When the laptop in question is given a static IP address

* network connectivity to the internet (ie, out the default route) works fine
* broadcast pings from laptop -> network can be seen by the AP
* broadcast pings from AP -> network (ie, the laptop should see it!) aren't received
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->adrian 
Responsible-Changed-By: adrian 
Responsible-Changed-When: Thu Jan 20 02:22:04 UTC 2011 
Responsible-Changed-Why:  
I'm going to take over the ath stuff. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=154153 

From: Adrian Chadd <adrian@freebsd.org>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/154153: AR5213 + MIPS + WPA group key packet corruption
Date: Thu, 20 Jan 2011 10:25:28 +0800

 Hardware specifics:
 
 * Board: Routerstation Pro (MIPS big-endian)
 * OS: FreeBSD-HEAD, as mentioned previously; I've also tested the
 latest HEAD very briefly but still need to do the more detailed tests
 below against it
 * Chipset:
     ath1: <Atheros 5212> irq 1 at device 18.0 on pci0
     ath1: AR5212 mac 5.9 RF2112 phy 4.3
     AR5213A-001 ; on a Ubiquiti SR-2 11g high-power mini-pci NIC
 
 Some (very) detailed digging has revealed some interesting facts.
 
 * With an atheros card (AR9280) in monitor mode, sniffing what is
 being transmitted over the wire, the packet is corrupted -after- the
 middle of the 8 byte IV. With WEP, there's a 3 byte IV and 1 byte key
 ID, giving a 4 byte WEP data prefix. With WPA, the IV is a 3 byte IV,
 a 1 byte key ID with "Extended IV" bit set, then 4 more bytes of IV.
 The packet gets corrupted on byte 4 of the WPA extended IV - ie, bytes
 0->3 of the WEP IV is fine, bytes 4->7 and the rest of the packet are
 garbage.
 
 * After the first group re-key, the packet contents are again valid
 and remain valid.
 
 * If the multicast keysearch is disabled, the same problem occurs.
 Here, there's still two TKIP keys being written into the hardware, but
 the MAC addresses are ff:ff:ff:ff:ff:ff.
 
 * If hardware crypto is disabled, the -same- problem occurs. Ie, the
 packet gets scrambled at the same point. After the first group rekey -
 which just writes out another CLR key in the same slot - things again
 come back to life. (Note: this may not be an entirely complete fix, as
 I was seeing garbage on the wire, but I have a feeling that "garbage"
 was "unencrypted packets that were being mistakenly decrypted." I
 think my patch to disable hardware crypto didn't properly punt packets
 to the software crypto layer. That needs to be investigated.) In any
 case, the IV wasn't corrupt.
 
 * If the TX path is patched so a packet w/ an encryption key that's a
 GROUP encryption key (ie, k->wk_flags & IEEE80211_KEY_GROUP) has the
 keyix forced to -1 - ie, don't use an encryption key - then the packet
 makes it out onto the wire fine. It's not encrypted at all, so the
 stations mistakenly decrypt an unencrypted frame, but the frame itself
 100% matches what's in the TX buffer.
 
 * The TX buffers are unchanged - ie, it isn't that the underlying
 mbuf(s) are being overwritten whilst the packet is in-flight.
 
 Stuff that should be done to (re)-verify:
 
 * Take the same software base and build + test on i386
 * Re-do these tests on the AR9160
 * Figure out what the heck the actual behaviour of "group multicast
 key search" is supposed to be - whether it's supposed to be TX, RX,
 some combination of both; what AR_KEYTABLE_VALID means in the context
 of a multicast group key (see Linux ath5k/ath9k key.c to see what I'm
 talking about.)

From: Adrian Chadd <adrian@freebsd.org>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/154153: AR5213 + MIPS + WPA group key packet corruption
Date: Thu, 20 Jan 2011 10:36:21 +0800

 Hardware specifics:
 
  Board: Routerstation Pro (MIPS big-endian)
 * OS: FreeBSD-HEAD, as mentioned previously; I've also tested the
 latest HEAD very briefly but still need to do the more detailed tests
 below against it
 * Chipset:
 =A0 =A0ath1: <Atheros 5212> irq 1 at device 18.0 on pci0
 =A0 =A0ath1: AR5212 mac 5.9 RF2112 phy 4.3
 =A0 =A0AR5213A-001 ; on a Ubiquiti SR-2 11g high-power mini-pci NIC
 Some (very) detailed digging has revealed some interesting facts.
 
  * With an atheros card (AR9280) in monitor mode, sniffing what is
  being transmitted over the wire, the packet is corrupted -after- the
  middle of the 8 byte IV. With WEP, there's a 3 byte IV and 1 byte key
  ID, giving a 4 byte WEP data prefix. With WPA, the IV is a 3 byte IV,
  a 1 byte key ID with "Extended IV" bit set, then 4 more bytes of IV.
  The packet gets corrupted on byte 4 of the WPA extended IV - ie, bytes
  0->3 of the WEP IV is fine, bytes 4->7 and the rest of the packet are
  garbage.
 
  * After the first group re-key, the packet contents are again valid
  and remain valid.
 
  * If the multicast keysearch is disabled, the same problem occurs.
  Here, there's still two TKIP keys being written into the hardware, but
  the MAC addresses are ff:ff:ff:ff:ff:ff.
 
  * If hardware crypto is disabled, the -same- problem occurs. Ie, the
  packet gets scrambled at the same point. After the first group rekey -
  which just writes out another CLR key in the same slot - things again
  come back to life. (Note: this may not be an entirely complete fix, as
  I was seeing garbage on the wire, but I have a feeling that "garbage"
  was "unencrypted packets that were being mistakenly decrypted." I
  think my patch to disable hardware crypto didn't properly punt packets
  to the software crypto layer. That needs to be investigated.) In any
  case, the IV wasn't corrupt.
 
  * If the TX path is patched so a packet w/ an encryption key that's a
  GROUP encryption key (ie, k->wk_flags & IEEE80211_KEY_GROUP) has the
  keyix forced to -1 - ie, don't use an encryption key - then the packet
  makes it out onto the wire fine. It's not encrypted at all, so the
  stations mistakenly decrypt an unencrypted frame, but the frame itself
  100% matches what's in the TX buffer.
 
  * The TX buffers are unchanged - ie, it isn't that the underlying
  mbuf(s) are being overwritten whilst the packet is in-flight.
 
  Stuff that should be done to (re)-verify:
 
  * Take the same software base and build + test on i386
  * Re-do these tests on the AR9160
  * Figure out what the heck the actual behaviour of "group multicast
  key search" is supposed to be - whether it's supposed to be TX, RX,
  some combination of both; what AR_KEYTABLE_VALID means in the context
  of a multicast group key (see Linux ath5k/ath9k key.c to see what I'm
  talking about.)
Responsible-Changed-From-To: adrian->freebsd-wireless 
Responsible-Changed-By: adrian 
Responsible-Changed-When: Sat Apr 9 03:06:54 UTC 2011 
Responsible-Changed-Why:  
Refile to mailing-list. 

It's worth mentioning that forcing a group key resync fixes the 
issue. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=154153 
>Unformatted:
