From owner-svn-src-head@freebsd.org Fri May 8 17:01:34 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 30B752DC6B8; Fri, 8 May 2020 17:01:34 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Jc720V9dz43dX; Fri, 8 May 2020 17:01:34 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0C0225A85; Fri, 8 May 2020 17:01:34 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 048H1Xnp047209; Fri, 8 May 2020 17:01:33 GMT (envelope-from adrian@FreeBSD.org) Received: (from adrian@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 048H1XiS047208; Fri, 8 May 2020 17:01:33 GMT (envelope-from adrian@FreeBSD.org) Message-Id: <202005081701.048H1XiS047208@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: adrian set sender to adrian@FreeBSD.org using -f From: Adrian Chadd Date: Fri, 8 May 2020 17:01:33 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r360819 - head/sys/net80211 X-SVN-Group: head X-SVN-Commit-Author: adrian X-SVN-Commit-Paths: head/sys/net80211 X-SVN-Commit-Revision: 360819 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 17:01:34 -0000 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,