Bug 154153 - [ath] AR5213 + MIPS + WPA group key packet corruption
Summary: [ath] AR5213 + MIPS + WPA group key packet corruption
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 9.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-20 02:20 UTC by Adrian Chadd
Modified: 2018-05-28 19:49 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer 2011-01-20 02:20:09 UTC
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
Comment 1 Adrian Chadd freebsd_committer 2011-01-20 02:22:04 UTC
Responsible Changed
From-To: freebsd-bugs->adrian

I'm going to take over the ath stuff.
Comment 2 Adrian Chadd freebsd_committer 2011-01-20 02:25:28 UTC
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.)
Comment 3 Adrian Chadd freebsd_committer 2011-01-20 02:36:21 UTC
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.)
Comment 4 Adrian Chadd freebsd_committer 2011-04-09 04:06:54 UTC
Responsible Changed
From-To: adrian->freebsd-wireless

Refile to mailing-list. 

It's worth mentioning that forcing a group key resync fixes the 
issue.
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:00 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.