From patchwork Fri May 4 06:50:38 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Manikanta Pubbisetty X-Patchwork-Id: 10380037 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 425D760353 for ; Fri, 4 May 2018 06:51:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3122A29345 for ; Fri, 4 May 2018 06:51:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 25DDD29359; Fri, 4 May 2018 06:51:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 705AB29356 for ; Fri, 4 May 2018 06:51:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=37++ATHFg+FiJvmk1ZYI4Ukl/nPVRUUotTiT/J97YKw=; b=cYR88bVdnJINd/eprGjS478dw gDXA8//wwj0SVqDUEMwvB9MimEAU8sQ7bCLqZoCi8HLCzGpBd/WMKkZKftPIizb4+g4DxD8wsmItY /zloTRixYH2/Vq1dtYp/yvHJBlrNz0kFQvN89NpWD/PKVBPbraF7l+/Y0P+oxY3FfG+rM02Qn4Exl xrgtiAb0dkQBEWG+v+6UI9ZDNWMT+LIf5HsTjTkOTVSUaLKtdrMatciAK7aCxxFyqtZwhsLyVeHYw EFqDdgLYr/48zcDuCuB+21DsbMUq4P37mVKUSJigGbaX//Ds+NfbBKFp1zRKKiJJ4mSksfH8UUsvB y+LVBJGrg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fEUYQ-0000yh-7t; Fri, 04 May 2018 06:50:54 +0000 Received: from smtp.codeaurora.org ([198.145.29.96]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fEUYL-0000xJ-U3 for ath10k@lists.infradead.org; Fri, 04 May 2018 06:50:51 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 0BDAE6055D; Fri, 4 May 2018 06:50:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1525416639; bh=qpQs88PEVuL9Me4UNUiuuGe/6964mCdOIZEYvNxrU5Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bj0PlGhgOk1jD9i8+MNEiKHivoHXfyqbuIRocmOtzkFCh7ZDUoPBc6CriXqbNwD/U FlSAG8LK0MagSakCzLsbyuc5xjF1jdwLBfMQg1UhjDMq5Dlhgz1THztBEXOegxR3Ag DIRTLovLQNkZRoYfM3JrZda0rx/4jzpiqvSo3vIU= Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 62C1D60249; Fri, 4 May 2018 06:50:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1525416638; bh=qpQs88PEVuL9Me4UNUiuuGe/6964mCdOIZEYvNxrU5Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Lu8Wq9zIKRW9j1oCogCl+y39fvC4Hb4nqGJqWfKIYeEN6D3oe+bCilOuwvcshuLnb FvWSpo9NVpJpYib1XxnEuCI9NnrYU8WF1sF2/ueCCRITTJR5T+h53RAw4vMND3fCVb ECE5erQUvX1mn9RSL/VeoPSpbh2lG48sbqlB6mKw= MIME-Version: 1.0 Date: Fri, 04 May 2018 12:20:38 +0530 From: Manikanta Pubbisetty To: johannes@sipsolutions.net Subject: Re: [PATCH] ath10k: add dynamic vlan support In-Reply-To: References: <1524232653-22573-1-git-send-email-mpubbise@codeaurora.org> <87r2n5auvq.fsf@kamboji.qca.qualcomm.com> Message-ID: X-Sender: mpubbise@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180503_235050_087400_32D41967 X-CRM114-Status: GOOD ( 20.63 ) X-BeenThere: ath10k@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sebastian Gottschall , linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, Kalle Valo Sender: "ath10k" Errors-To: ath10k-bounces+patchwork-ath10k=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Johannes, It seems like commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled devices") has broken 4-addr operation on crypto controlled devices as reported by sebastian. The commit was mainly focused in addressing the problem in supporting VLANs on crypto controlled devices but since 4-addr mode is also dependent on AP_VLAN interface, this commit breaks the 4-addr AP mode. I have couple of ideas on how to address the problem, 1) Add a new hw_flag and based on the hardware flag, allow/disallow the creation of AP_VLAN interface. SW_CRYPTO_CONTROL))) goto out_unsupported; } Please let me know which is the better way to deal the problem. Thanks, Manikanta On 2018-04-24 14:39, Sebastian Gottschall wrote: > consider my comment regarding vlan_ap. > this patch will break wds ap / wds sta support with latest mac80211 > (see also my post on the wireless mailing list about the breaking > patch in mac80211) > so AP_VLAN must be masked always for all chipsets. otherwise wds > breaks and this is not just a guess. i tested it yesterday using this > patch and found > the cause of the issue > > the following lines > >   +    if (test_bit(WMI_SERVICE_PER_PACKET_SW_ENCRYPT, > ar->wmi.svc_map)) { > +        ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN); > +        ar->hw->wiphy->software_iftypes |= > BIT(NL80211_IFTYPE_AP_VLAN); > +    } > > > must be just > > +        ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN); > +        ar->hw->wiphy->software_iftypes |= > BIT(NL80211_IFTYPE_AP_VLAN); > > everthing else will cause a regression > > Am 24.04.2018 um 10:09 schrieb Kalle Valo: >> Manikanta Pubbisetty writes: >> >>> Mutlicast/broadcast traffic destined for a particular vlan group will >>> always be encrypted in software. To enable dynamic VLANs, it requires >>> driver support for sending software encrypted packets. >>> >>> In ath10k, sending sw encrypted frames is allowed only when we insmod >>> the driver with cryptmode param set to 1, this configuration disables >>> hardware crypto and enables RAW mode implicitly. Since, enabling raw >>> mode has performance impact, this cannot be considered as an ideal >>> solution for supporting VLANs in the driver. >>> >>> As an alternative take, in this approach, cryptographic keys for >>> unicast traffic(per peer PTKs) and keys for non-vlan group traffic >>> will be configured in hardware, allowing hardware encryption for >>> unicast >>> and non-vlan group traffic. Only vlan group traffic will be encrypted >>> in >>> software and pushed to the target with encap mode set to RAW in the >>> TX >>> descriptors. >>> >>> Not all firmwares can support this type of key configuration(having >>> few >>> keys installed in hardware and few only in software); for this >>> purpose a >>> new WMI service flag "WMI_SERVICE_PER_PACKET_SW_ENCRYPT" is >>> introduced to >>> advertise this support. >>> >>> Also, adding the logic required to send sw encrypted frames in raw >>> mode. >>> >>> Tested this change on QCA9984(firmware version 10.4-3.5.3-00057). >>> >>> Signed-off-by: Manikanta Pubbisetty >> Your name in patchwork is wrong and hence my script uses the wrong >> name. Please fix it by registering to patchwork[1] where it's possible >> to change your name during registration, but only one time. If that >> doesn't work then send a request to helpdesk@kernel.org and the admins >> can fix it. >> >> [1] https://patchwork.kernel.org/register/ >> diff --git a/include/net/mac80211.h b/include/net/mac80211.h index d2279b2..301d9c38 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -2084,6 +2084,11 @@ struct ieee80211_txq { * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't * support QoS NDP for AP probing - that's most likely a driver bug. * + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting + * frames encrypted in software, only valid when SW_CRYPTO_CONTROL + * is enabled. Based on this flag, mac80211 can allow/disallow VLAN + * operations in the BSS. + * * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays */ enum ieee80211_hw_flags { @@ -2129,6 +2134,7 @@ enum ieee80211_hw_flags { IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA, IEEE80211_HW_DEAUTH_NEED_MGD_TX_PREP, IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP, + IEEE80211_HW_SUPPORTS_SW_ENCRYPT, /* keep last, obviously */ NUM_IEEE80211_HW_FLAGS diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index 555e389..c825d27 100644 --- a/net/mac80211/iface.c +++ b/net/mac80211/iface.c @@ -1736,6 +1736,11 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name, ASSERT_RTNL(); + if ((type == NL80211_IFTYPE_AP_VLAN) && !params->use_4addr && + ieee80211_hw_check(local->hw, SW_CRYPTO_CONTROL) && + !ieee80211_hw_check(local->hw, SUPPORTS_SW_ENCRYPT)) + return -EOPNOTSUPP; + if (type == NL80211_IFTYPE_P2P_DEVICE || type == NL80211_IFTYPE_NAN) { struct wireless_dev *wdev; 2) Allow mac80211 to call set_key for GTKs on AP_VLAN interfaces for crypto controlled devices, let the driver decide whether to return '1' or some error code based on their support for transmitting sw encrypted frames. I am little skeptical with this approach as drivers are totally unaware of AP_VLAN interfaces. diff --git a/net/mac80211/key.c b/net/mac80211/key.c index ee0d0cc..0ff5597 100644 --- a/net/mac80211/key.c +++ b/net/mac80211/key.c @@ -167,7 +167,8 @@ static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key) * The driver doesn't know anything about VLAN interfaces. * Hence, don't send GTKs for VLAN interfaces to the driver. */ - if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE)) + if ((!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE) && + !ieee80211_hw_check(&key->local->hw,