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
Responsible Changed From-To: freebsd-bugs->adrian I'm going to take over the ath stuff.
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.)
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 Refile to mailing-list. It's worth mentioning that forcing a group key resync fixes the issue.
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.