Date: Fri, 8 May 2020 17:01:33 +0000 (UTC) From: Adrian Chadd <adrian@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r360819 - head/sys/net80211 Message-ID: <202005081701.048H1XiS047208@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: adrian Date: Fri May 8 17:01:33 2020 New Revision: 360819 URL: https://svnweb.freebsd.org/changeset/base/360819 Log: [net80211] Use the unicast key when transmitting DWDS AP multicast frames. I'm still not sure whether this is the full solution, but here goes. I have a two node DWDS setup - a main AP with the ethernet bridge uplink and a satellite AP in the back of the house. They're both AR9344+AR9580 dual band 11n APs. The problem was that multicast frames was not going from the DWDS AP to the DWDS STA. Unicast frames are fine, and multicast frames from the DWDS STA to AP are fine. Now, multicast and unicast frames from the STA -> AP are just transmitted using the unicast key. That's fine. However, the AP -> STA multicast frames by default are transmitted using the current default / multicast key, the shared one between all STAs in a BSS. Now, the DWDS implementation ignores non WDS frames - it only allows about 4 address frames outside of management / EAPOL frames! - so the STA side ignores the normal multicast frames. Instead, the AP side uses ieee80211_dwds_mcast() to send multicast frames to each WDS VAP that was created as part of the "dynamic" part of DWDS. This should be queuing them individually to each node instead of using the normal multicast send path; and this is how they should get turned into 4-addr WDS frames. HOWEVER, ieee80211_encap() was trying to use the default TX key to queue them rather than the unicast key that's already setup. Since this synthetic node doesn't have the default TX key setup, transmission fails. Things would be fine in WEP and in open mode because in both cases you would have static keys (or no keys) setup. It just fails in WPA mode. This resolves the issue. AP DWDS multicast is now sent using the unicast key just like in STA mode and I'm pretty sure the STA mode side will stil work fine (as it's a STA VAP with a DWDS flag..) Tested: * TL-WDR3600/4300 APs Modified: head/sys/net80211/ieee80211_output.c Modified: head/sys/net80211/ieee80211_output.c ============================================================================== --- head/sys/net80211/ieee80211_output.c Fri May 8 16:41:23 2020 (r360818) +++ head/sys/net80211/ieee80211_output.c Fri May 8 17:01:33 2020 (r360819) @@ -1471,10 +1471,27 @@ ieee80211_encap(struct ieee80211vap *vap, struct ieee8 if (vap->iv_opmode == IEEE80211_M_STA || !IEEE80211_IS_MULTICAST(eh.ether_dhost) || (vap->iv_opmode == IEEE80211_M_WDS && - (vap->iv_flags_ext & IEEE80211_FEXT_WDSLEGACY))) + (vap->iv_flags_ext & IEEE80211_FEXT_WDSLEGACY))) { key = ieee80211_crypto_getucastkey(vap, ni); - else + } else if ((vap->iv_opmode == IEEE80211_M_WDS) && + (! (vap->iv_flags_ext & IEEE80211_FEXT_WDSLEGACY))) { + /* + * Use ucastkey for DWDS transmit nodes, multicast + * or otherwise. + * + * This is required to ensure that multicast frames + * from a DWDS AP to a DWDS STA is encrypted with + * a key that can actually work. + * + * There's no default key for multicast traffic + * on a DWDS WDS VAP node (note NOT the DWDS enabled + * AP VAP, the dynamically created per-STA WDS node) + * so encap fails and transmit fails. + */ + key = ieee80211_crypto_getucastkey(vap, ni); + } else { key = ieee80211_crypto_getmcastkey(vap, ni); + } if (key == NULL && (m->m_flags & M_EAPOL) == 0) { IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_CRYPTO, eh.ether_dhost,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202005081701.048H1XiS047208>