* iwlwifi: 9260: Spurious "Unhandled alg: 0x707" and 0x71b
From: Tee Hao Wei @ 2019-08-16 8:55 UTC (permalink / raw)
To: Ilan Peer, Emmanuel Grumbach; +Cc: linux-wireless
Hi,
I've been getting "Unhandled alg: 0x707" or 0x71b randomly
on my Intel 9260. It seems to happen most often when it
associates to a new AP (or roams to a different one that
has the same SSID/authentication). It also seems to happen
only with particular APs. (I don't have access to the APs,
so there's not much I know about them.)
I applied the two patches mentioned in Bugzilla #203593[1]
i.e. "iwlwifi: mvm: Allow multicast data frames only when
associated" and "iwlwifi: mvm: Allow multicast data frames
only when authorized" on top of iwlwifi in 5.2.8, which
improved the situation a lot, but it still happens pretty
frequently.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=203593
I'll try to collect some debug data soon. Also, I'll try
to see if my 8260 has the same issues.
Is there anything else I should try or any other patches I
should backport?
Thanks.
--
Hao Wei
^ permalink raw reply
* Re: [PATCH 0/2] Use ccm(aes) aead transform in staging drivers
From: Ard Biesheuvel @ 2019-08-16 8:31 UTC (permalink / raw)
To: Christina Quast
Cc: Greg Kroah-Hartman, Payal Kshirsagar, Eric Biggers, Herbert Xu,
open list:ANDROID DRIVERS, Linux Kernel Mailing List,
Anushka Shukla, Bartlomiej Zolnierkiewicz, Zach Turner,
<linux-wireless@vger.kernel.org>, Johannes Berg,
David S. Miller, open list:HARDWARE RANDOM NUMBER GENERATOR CORE
In-Reply-To: <20190816065936.12214-1-contact@christina-quast.de>
On Fri, 16 Aug 2019 at 10:00, Christina Quast
<contact@christina-quast.de> wrote:
>
> Use ccm(aes) aead transform instead of invoking the AES block cipher
> block by block.
>
Thanks! This eliminates another two users of the bare cipher API,
which is not the right abstraction for drivers to use.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I don't have the hardware, so I can't test this.
> Christina Quast (2):
> staging: rtl8192u: ieee80211: ieee80211_crypt_ccmp.c: Use crypto API
> ccm(aes)
> staging: rtl8192e: rtllib_crypt_ccmp.c: Use crypto API ccm(aes)
>
> drivers/staging/rtl8192e/Kconfig | 1 +
> drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 187 ++++++++----------
> drivers/staging/rtl8192u/Kconfig | 2 +
> .../rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 187 ++++++++----------
> 4 files changed, 159 insertions(+), 218 deletions(-)
>
> --
> 2.20.1
>
^ permalink raw reply
* RE: [PATCH] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
From: Tony Chuang @ 2019-08-16 8:06 UTC (permalink / raw)
To: Tony Chuang, Jian-Hong Pan, Kalle Valo, David S . Miller
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D18929BF@RTITMBSVM04.realtek.com.tw>
Hi,
A few more questions below
> > From: Jian-Hong Pan [mailto:jian-hong@endlessm.com]
> >
> > There is a mass of jobs between spin lock and unlock in the hardware
> > IRQ which will occupy much time originally. To make system work more
> > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > reduce the time in hardware IRQ.
> >
> > Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> > ---
> > drivers/net/wireless/realtek/rtw88/pci.c | 36 +++++++++++++++++++-----
> > 1 file changed, 29 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index 00ef229552d5..355606b167c6 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int
> irq,
> > void *dev)
> > {
> > struct rtw_dev *rtwdev = dev;
> > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > - u32 irq_status[4];
> > + unsigned long flags;
> >
> > - spin_lock(&rtwpci->irq_lock);
> > + spin_lock_irqsave(&rtwpci->irq_lock, flags);
I think you can use 'spin_lock()' here as it's in IRQ context?
> > if (!rtwpci->irq_enabled)
> > goto out;
> >
> > + /* disable RTW PCI interrupt to avoid more interrupts before the end of
> > + * thread function
> > + */
> > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
Why do we need rtw_pci_disable_interrupt() here.
Have you done any experiment and decided to add this.
If you have can you share your results to me?
> > +out:
> > + spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
spin_unlock()
> > +
> > + return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > +{
> > + struct rtw_dev *rtwdev = dev;
> > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > + unsigned long flags;
> > + u32 irq_status[4];
> > +
> > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> >
> > if (irq_status[0] & IMR_MGNTDOK)
> > @@ -891,8 +908,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int
> irq,
> > void *dev)
> > if (irq_status[0] & IMR_ROK)
> > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> >
> > -out:
> > - spin_unlock(&rtwpci->irq_lock);
> > + /* all of the jobs for this interrupt have been done */
> > + spin_lock_irqsave(&rtwpci->irq_lock, flags);
>
> Shouldn't we protect the ISRs above?
>
> This patch could actually reduce the time of IRQ.
> But I think I need to further test it with PCI MSI interrupt.
> https://patchwork.kernel.org/patch/11081539/
>
> Maybe we could drop the "rtw_pci_[enable/disable]_interrupt" when MSI
> Is enabled with this patch.
>
> > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
> > + rtw_pci_enable_interrupt(rtwdev, rtwpci);
> > + spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
> >
> > return IRQ_HANDLED;
> > }
> > @@ -1152,8 +1172,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
> > goto err_destroy_pci;
> > }
> >
> > - ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
> > - IRQF_SHARED, KBUILD_MODNAME, rtwdev);
> > + ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
> > + rtw_pci_interrupt_handler,
> > + rtw_pci_interrupt_threadfn,
> > + IRQF_SHARED, KBUILD_MODNAME, rtwdev);
> > if (ret) {
> > ieee80211_unregister_hw(hw);
> > goto err_destroy_pci;
> > @@ -1192,7 +1214,7 @@ static void rtw_pci_remove(struct pci_dev
> *pdev)
> > rtw_pci_disable_interrupt(rtwdev, rtwpci);
> > rtw_pci_destroy(rtwdev, pdev);
> > rtw_pci_declaim(rtwdev, pdev);
> > - free_irq(rtwpci->pdev->irq, rtwdev);
> > + devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
> > rtw_core_deinit(rtwdev);
> > ieee80211_free_hw(hw);
> > }
> > --
> > 2.20.1
>
> Yan-Hsuan
>
Thanks
Yan-Hsuan
^ permalink raw reply
* Re: Ap mode regression in linux-5.3-rc1 in rt2800usb
From: Emil Karlson @ 2019-08-16 8:00 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <20190814085018.GA29199@redhat.com>
Greetings
On Wed, 14 Aug 2019 10:50:19 +0200
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> (cc linux-wireless mailing list)
>
> On Tue, Aug 13, 2019 at 09:50:00PM +0300, Emil Karlson wrote:
> > Greetings
> >
> > After upgrading my ap running rt2800usb to linux-5.3-rc1 I noticed
> > an unusual problem of not being able to connect to my ap with my
> > android devices (nexus7/flo and nexus5x/bullhead), from tcpdump it
> > seemed ap was receiving packets from the android devices after
> > successful association, but android devices were not seeing the
> > dhcp replies.
> >
> > I reverted drivers/net/wireless/ralink to the state it is in v5.2.8
> > and android clients can connect again normally. I did not
> > explicitly set watchdog parameter to any value.
> Most suspicious are 710e6cc1595e and 41a531ffa4c5 .
It seems to me that reverting only
710e6cc1595e25378c4b9977f7a8b4ad4a72a109
allows all my android devices to successfully connect to the internet.
Best Regards
-Emil
^ permalink raw reply
* RE: [PATCH] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
From: Tony Chuang @ 2019-08-16 7:54 UTC (permalink / raw)
To: Jian-Hong Pan, Kalle Valo, David S . Miller
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com
In-Reply-To: <20190816063109.4699-1-jian-hong@endlessm.com>
> From: Jian-Hong Pan [mailto:jian-hong@endlessm.com]
>
> There is a mass of jobs between spin lock and unlock in the hardware
> IRQ which will occupy much time originally. To make system work more
> efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> reduce the time in hardware IRQ.
>
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> ---
> drivers/net/wireless/realtek/rtw88/pci.c | 36 +++++++++++++++++++-----
> 1 file changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> b/drivers/net/wireless/realtek/rtw88/pci.c
> index 00ef229552d5..355606b167c6 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> void *dev)
> {
> struct rtw_dev *rtwdev = dev;
> struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> - u32 irq_status[4];
> + unsigned long flags;
>
> - spin_lock(&rtwpci->irq_lock);
> + spin_lock_irqsave(&rtwpci->irq_lock, flags);
> if (!rtwpci->irq_enabled)
> goto out;
>
> + /* disable RTW PCI interrupt to avoid more interrupts before the end of
> + * thread function
> + */
> + rtw_pci_disable_interrupt(rtwdev, rtwpci);
> +out:
> + spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
> +
> + return IRQ_WAKE_THREAD;
> +}
> +
> +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> +{
> + struct rtw_dev *rtwdev = dev;
> + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> + unsigned long flags;
> + u32 irq_status[4];
> +
> rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
>
> if (irq_status[0] & IMR_MGNTDOK)
> @@ -891,8 +908,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> void *dev)
> if (irq_status[0] & IMR_ROK)
> rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
>
> -out:
> - spin_unlock(&rtwpci->irq_lock);
> + /* all of the jobs for this interrupt have been done */
> + spin_lock_irqsave(&rtwpci->irq_lock, flags);
Shouldn't we protect the ISRs above?
This patch could actually reduce the time of IRQ.
But I think I need to further test it with PCI MSI interrupt.
https://patchwork.kernel.org/patch/11081539/
Maybe we could drop the "rtw_pci_[enable/disable]_interrupt" when MSI
Is enabled with this patch.
> + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
> + rtw_pci_enable_interrupt(rtwdev, rtwpci);
> + spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
>
> return IRQ_HANDLED;
> }
> @@ -1152,8 +1172,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
> goto err_destroy_pci;
> }
>
> - ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
> - IRQF_SHARED, KBUILD_MODNAME, rtwdev);
> + ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
> + rtw_pci_interrupt_handler,
> + rtw_pci_interrupt_threadfn,
> + IRQF_SHARED, KBUILD_MODNAME, rtwdev);
> if (ret) {
> ieee80211_unregister_hw(hw);
> goto err_destroy_pci;
> @@ -1192,7 +1214,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
> rtw_pci_disable_interrupt(rtwdev, rtwpci);
> rtw_pci_destroy(rtwdev, pdev);
> rtw_pci_declaim(rtwdev, pdev);
> - free_irq(rtwpci->pdev->irq, rtwdev);
> + devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
> rtw_core_deinit(rtwdev);
> ieee80211_free_hw(hw);
> }
> --
> 2.20.1
Yan-Hsuan
^ permalink raw reply
* [PATCH 1/2] staging: rtl8192u: ieee80211: ieee80211_crypt_ccmp.c: Use crypto API ccm(aes)
From: Christina Quast @ 2019-08-16 6:59 UTC (permalink / raw)
To: ard.biesheuvel
Cc: Christina Quast, Greg Kroah-Hartman, Payal Kshirsagar,
Eric Biggers, Herbert Xu, devel, linux-kernel, Anushka Shukla,
Bartlomiej Zolnierkiewicz, Zach Turner, linux-wireless,
Johannes Berg, David S. Miller, linux-crypto
In-Reply-To: <20190816065936.12214-1-contact@christina-quast.de>
Use ccm(aes) aead transform instead of invoking the AES block cipher
block by block.
Signed-off-by: Christina Quast <contact@christina-quast.de>
---
drivers/staging/rtl8192u/Kconfig | 2 +
.../rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 187 ++++++++----------
2 files changed, 81 insertions(+), 108 deletions(-)
diff --git a/drivers/staging/rtl8192u/Kconfig b/drivers/staging/rtl8192u/Kconfig
index 22c2165e8b1c..1edca5c304fb 100644
--- a/drivers/staging/rtl8192u/Kconfig
+++ b/drivers/staging/rtl8192u/Kconfig
@@ -6,3 +6,5 @@ config RTL8192U
select WIRELESS_EXT
select WEXT_PRIV
select CRYPTO
+ select CRYPTO_AES
+ select CRYPTO_CCM
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
index d7188b3f3190..aecee42be95e 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
@@ -19,6 +19,7 @@
#include "ieee80211.h"
#include <linux/crypto.h>
+#include <crypto/aead.h>
#include <linux/scatterlist.h>
MODULE_AUTHOR("Jouni Malinen");
@@ -44,20 +45,13 @@ struct ieee80211_ccmp_data {
int key_idx;
- struct crypto_tfm *tfm;
+ struct crypto_aead *tfm;
/* scratch buffers for virt_to_page() (crypto API) */
- u8 tx_b0[AES_BLOCK_LEN], tx_b[AES_BLOCK_LEN],
- tx_e[AES_BLOCK_LEN], tx_s0[AES_BLOCK_LEN];
- u8 rx_b0[AES_BLOCK_LEN], rx_b[AES_BLOCK_LEN], rx_a[AES_BLOCK_LEN];
+ u8 tx_aad[2 * AES_BLOCK_LEN];
+ u8 rx_aad[2 * AES_BLOCK_LEN];
};
-static void ieee80211_ccmp_aes_encrypt(struct crypto_tfm *tfm,
- const u8 pt[16], u8 ct[16])
-{
- crypto_cipher_encrypt_one((void *)tfm, ct, pt);
-}
-
static void *ieee80211_ccmp_init(int key_idx)
{
struct ieee80211_ccmp_data *priv;
@@ -67,7 +61,7 @@ static void *ieee80211_ccmp_init(int key_idx)
goto fail;
priv->key_idx = key_idx;
- priv->tfm = (void *)crypto_alloc_cipher("aes", 0, 0);
+ priv->tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv->tfm)) {
pr_debug("ieee80211_crypt_ccmp: could not allocate crypto API aes\n");
priv->tfm = NULL;
@@ -79,7 +73,7 @@ static void *ieee80211_ccmp_init(int key_idx)
fail:
if (priv) {
if (priv->tfm)
- crypto_free_cipher((void *)priv->tfm);
+ crypto_free_aead(priv->tfm);
kfree(priv);
}
@@ -91,28 +85,17 @@ static void ieee80211_ccmp_deinit(void *priv)
struct ieee80211_ccmp_data *_priv = priv;
if (_priv && _priv->tfm)
- crypto_free_cipher((void *)_priv->tfm);
+ crypto_free_aead(_priv->tfm);
kfree(priv);
}
-static inline void xor_block(u8 *b, u8 *a, size_t len)
-{
- int i;
-
- for (i = 0; i < len; i++)
- b[i] ^= a[i];
-}
-
-static void ccmp_init_blocks(struct crypto_tfm *tfm,
- struct rtl_80211_hdr_4addr *hdr,
- u8 *pn, size_t dlen, u8 *b0, u8 *auth,
- u8 *s0)
+static int ccmp_init_iv_and_aad(struct rtl_80211_hdr_4addr *hdr,
+ u8 *pn, u8 *iv, u8 *aad)
{
u8 *pos, qc = 0;
size_t aad_len;
u16 fc;
int a4_included, qc_included;
- u8 aad[2 * AES_BLOCK_LEN];
fc = le16_to_cpu(hdr->frame_ctl);
a4_included = ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) ==
@@ -133,18 +116,20 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm,
qc = *pos & 0x0f;
aad_len += 2;
}
- /* CCM Initial Block:
- * Flag (Include authentication header, M=3 (8-octet MIC),
- * L=1 (2-octet Dlen))
- * Nonce: 0x00 | A2 | PN
- * Dlen
+
+ /* In CCM, the initial vectors (IV) used for CTR mode encryption and CBC
+ * mode authentication are not allowed to collide, yet both are derived
+ * from the same vector. We only set L := 1 here to indicate that the
+ * data size can be represented in (L+1) bytes. The CCM layer will take
+ * care of storing the data length in the top (L+1) bytes and setting
+ * and clearing the other bits as is required to derive the two IVs.
*/
- b0[0] = 0x59;
- b0[1] = qc;
- memcpy(b0 + 2, hdr->addr2, ETH_ALEN);
- memcpy(b0 + 8, pn, CCMP_PN_LEN);
- b0[14] = (dlen >> 8) & 0xff;
- b0[15] = dlen & 0xff;
+ iv[0] = 0x1;
+
+ /* Nonce: QC | A2 | PN */
+ iv[1] = qc;
+ memcpy(iv + 2, hdr->addr2, ETH_ALEN);
+ memcpy(iv + 8, pn, CCMP_PN_LEN);
/* AAD:
* FC with bits 4..6 and 11..13 masked to zero; 14 is always one
@@ -154,32 +139,21 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm,
* QC (if present)
*/
pos = (u8 *)hdr;
- aad[0] = 0; /* aad_len >> 8 */
- aad[1] = aad_len & 0xff;
- aad[2] = pos[0] & 0x8f;
- aad[3] = pos[1] & 0xc7;
- memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN);
+ aad[0] = pos[0] & 0x8f;
+ aad[1] = pos[1] & 0xc7;
+ memcpy(aad + 2, hdr->addr1, 3 * ETH_ALEN);
pos = (u8 *)&hdr->seq_ctl;
- aad[22] = pos[0] & 0x0f;
- aad[23] = 0; /* all bits masked */
- memset(aad + 24, 0, 8);
+ aad[20] = pos[0] & 0x0f;
+ aad[21] = 0; /* all bits masked */
+ memset(aad + 22, 0, 8);
if (a4_included)
- memcpy(aad + 24, hdr->addr4, ETH_ALEN);
+ memcpy(aad + 22, hdr->addr4, ETH_ALEN);
if (qc_included) {
- aad[a4_included ? 30 : 24] = qc;
+ aad[a4_included ? 28 : 22] = qc;
/* rest of QC masked */
}
- /* Start with the first block and AAD */
- ieee80211_ccmp_aes_encrypt(tfm, b0, auth);
- xor_block(auth, aad, AES_BLOCK_LEN);
- ieee80211_ccmp_aes_encrypt(tfm, auth, auth);
- xor_block(auth, &aad[AES_BLOCK_LEN], AES_BLOCK_LEN);
- ieee80211_ccmp_aes_encrypt(tfm, auth, auth);
- b0[0] &= 0x07;
- b0[14] = 0;
- b0[15] = 0;
- ieee80211_ccmp_aes_encrypt(tfm, b0, s0);
+ return aad_len;
}
static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
@@ -220,36 +194,34 @@ static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
hdr = (struct rtl_80211_hdr_4addr *)skb->data;
if (!tcb_desc->bHwSec) {
- int blocks, last, len;
- u8 *mic;
- u8 *b0 = key->tx_b0;
- u8 *b = key->tx_b;
- u8 *e = key->tx_e;
- u8 *s0 = key->tx_s0;
+ struct aead_request *req;
+ struct scatterlist sg[2];
+ u8 *aad = key->tx_aad;
+ u8 iv[AES_BLOCK_LEN];
+ int aad_len, ret;
+ size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN;
- /* mic is moved to here by john */
- mic = skb_put(skb, CCMP_MIC_LEN);
+ req = aead_request_alloc(key->tfm, GFP_ATOMIC);
+ if (!req)
+ return -ENOMEM;
- ccmp_init_blocks(key->tfm, hdr, key->tx_pn, data_len, b0, b, s0);
+ aad_len = ccmp_init_iv_and_aad(hdr, key->tx_pn, iv, aad);
- blocks = DIV_ROUND_UP(data_len, AES_BLOCK_LEN);
- last = data_len % AES_BLOCK_LEN;
+ skb_put(skb, CCMP_MIC_LEN);
- for (i = 1; i <= blocks; i++) {
- len = (i == blocks && last) ? last : AES_BLOCK_LEN;
- /* Authentication */
- xor_block(b, pos, len);
- ieee80211_ccmp_aes_encrypt(key->tfm, b, b);
- /* Encryption, with counter */
- b0[14] = (i >> 8) & 0xff;
- b0[15] = i & 0xff;
- ieee80211_ccmp_aes_encrypt(key->tfm, b0, e);
- xor_block(pos, e, len);
- pos += len;
- }
+ sg_init_table(sg, 2);
+ sg_set_buf(&sg[0], aad, aad_len);
+ sg_set_buf(&sg[1], skb->data + hdr_len + CCMP_HDR_LEN,
+ data_len + CCMP_MIC_LEN);
- for (i = 0; i < CCMP_MIC_LEN; i++)
- mic[i] = b[i] ^ s0[i];
+ aead_request_set_callback(req, 0, NULL, NULL);
+ aead_request_set_ad(req, aad_len);
+ aead_request_set_crypt(req, sg, sg, data_len, iv);
+
+ ret = crypto_aead_encrypt(req);
+ aead_request_free(req);
+
+ return ret;
}
return 0;
}
@@ -309,33 +281,31 @@ static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
return -4;
}
if (!tcb_desc->bHwSec) {
- size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN - CCMP_MIC_LEN;
- u8 *mic = skb->data + skb->len - CCMP_MIC_LEN;
- u8 *b0 = key->rx_b0;
- u8 *b = key->rx_b;
- u8 *a = key->rx_a;
- int i, blocks, last, len;
+ struct aead_request *req;
+ struct scatterlist sg[2];
+ u8 *aad = key->rx_aad;
+ u8 iv[AES_BLOCK_LEN];
+ int aad_len, ret;
+ size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN;
- ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, a, b);
- xor_block(mic, b, CCMP_MIC_LEN);
+ req = aead_request_alloc(key->tfm, GFP_ATOMIC);
+ if (!req)
+ return -ENOMEM;
- blocks = DIV_ROUND_UP(data_len, AES_BLOCK_LEN);
- last = data_len % AES_BLOCK_LEN;
+ aad_len = ccmp_init_iv_and_aad(hdr, pn, iv, aad);
- for (i = 1; i <= blocks; i++) {
- len = (i == blocks && last) ? last : AES_BLOCK_LEN;
- /* Decrypt, with counter */
- b0[14] = (i >> 8) & 0xff;
- b0[15] = i & 0xff;
- ieee80211_ccmp_aes_encrypt(key->tfm, b0, b);
- xor_block(pos, b, len);
- /* Authentication */
- xor_block(a, pos, len);
- ieee80211_ccmp_aes_encrypt(key->tfm, a, a);
- pos += len;
- }
+ sg_init_table(sg, 2);
+ sg_set_buf(&sg[0], aad, aad_len);
+ sg_set_buf(&sg[1], pos, data_len);
- if (memcmp(mic, a, CCMP_MIC_LEN) != 0) {
+ aead_request_set_callback(req, 0, NULL, NULL);
+ aead_request_set_ad(req, aad_len);
+ aead_request_set_crypt(req, sg, sg, data_len, iv);
+
+ ret = crypto_aead_decrypt(req);
+ aead_request_free(req);
+
+ if (ret) {
if (net_ratelimit()) {
netdev_dbg(skb->dev, "CCMP: decrypt failed: STA=%pM\n",
hdr->addr2);
@@ -358,12 +328,11 @@ static int ieee80211_ccmp_set_key(void *key, int len, u8 *seq, void *priv)
{
struct ieee80211_ccmp_data *data = priv;
int keyidx;
- struct crypto_tfm *tfm = data->tfm;
+ struct crypto_aead *tfm = data->tfm;
keyidx = data->key_idx;
memset(data, 0, sizeof(*data));
data->key_idx = keyidx;
- data->tfm = tfm;
if (len == CCMP_TK_LEN) {
memcpy(data->key, key, CCMP_TK_LEN);
data->key_set = 1;
@@ -375,7 +344,9 @@ static int ieee80211_ccmp_set_key(void *key, int len, u8 *seq, void *priv)
data->rx_pn[4] = seq[1];
data->rx_pn[5] = seq[0];
}
- crypto_cipher_setkey((void *)data->tfm, data->key, CCMP_TK_LEN);
+ if (crypto_aead_setauthsize(tfm, CCMP_MIC_LEN) ||
+ crypto_aead_setkey(tfm, data->key, CCMP_TK_LEN))
+ return -1;
} else if (len == 0) {
data->key_set = 0;
} else {
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] staging: rtl8192e: rtllib_crypt_ccmp.c: Use crypto API ccm(aes)
From: Christina Quast @ 2019-08-16 6:59 UTC (permalink / raw)
To: ard.biesheuvel
Cc: Christina Quast, Greg Kroah-Hartman, Payal Kshirsagar,
Eric Biggers, Herbert Xu, devel, linux-kernel, Anushka Shukla,
Bartlomiej Zolnierkiewicz, Zach Turner, linux-wireless,
Johannes Berg, David S. Miller, linux-crypto
In-Reply-To: <20190816065936.12214-1-contact@christina-quast.de>
Use ccm(aes) aead transform instead of invoking the AES block cipher
block by block.
Signed-off-by: Christina Quast <contact@christina-quast.de>
---
drivers/staging/rtl8192e/Kconfig | 1 +
drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 187 ++++++++-----------
2 files changed, 78 insertions(+), 110 deletions(-)
diff --git a/drivers/staging/rtl8192e/Kconfig b/drivers/staging/rtl8192e/Kconfig
index 11528d17bb3c..1007eea6c8fc 100644
--- a/drivers/staging/rtl8192e/Kconfig
+++ b/drivers/staging/rtl8192e/Kconfig
@@ -15,6 +15,7 @@ config RTLLIB_CRYPTO_CCMP
tristate "Support for rtllib CCMP crypto"
depends on RTLLIB
select CRYPTO_AES
+ select CRYPTO_CCM
default y
help
CCMP crypto driver for rtllib.
diff --git a/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c b/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
index 2581ed6d14fa..44ec45d5c87f 100644
--- a/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
+++ b/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c
@@ -17,6 +17,7 @@
#include "rtllib.h"
#include <linux/crypto.h>
+#include <crypto/aead.h>
#include <linux/scatterlist.h>
@@ -39,20 +40,13 @@ struct rtllib_ccmp_data {
int key_idx;
- struct crypto_tfm *tfm;
+ struct crypto_aead *tfm;
/* scratch buffers for virt_to_page() (crypto API) */
- u8 tx_b0[AES_BLOCK_LEN], tx_b[AES_BLOCK_LEN],
- tx_e[AES_BLOCK_LEN], tx_s0[AES_BLOCK_LEN];
- u8 rx_b0[AES_BLOCK_LEN], rx_b[AES_BLOCK_LEN], rx_a[AES_BLOCK_LEN];
+ u8 tx_aad[2 * AES_BLOCK_LEN];
+ u8 rx_aad[2 * AES_BLOCK_LEN];
};
-static void rtllib_ccmp_aes_encrypt(struct crypto_tfm *tfm,
- const u8 pt[16], u8 ct[16])
-{
- crypto_cipher_encrypt_one((void *)tfm, ct, pt);
-}
-
static void *rtllib_ccmp_init(int key_idx)
{
struct rtllib_ccmp_data *priv;
@@ -62,7 +56,7 @@ static void *rtllib_ccmp_init(int key_idx)
goto fail;
priv->key_idx = key_idx;
- priv->tfm = (void *)crypto_alloc_cipher("aes", 0, 0);
+ priv->tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(priv->tfm)) {
pr_debug("Could not allocate crypto API aes\n");
priv->tfm = NULL;
@@ -73,7 +67,7 @@ static void *rtllib_ccmp_init(int key_idx)
fail:
if (priv) {
if (priv->tfm)
- crypto_free_cipher((void *)priv->tfm);
+ crypto_free_aead(priv->tfm);
kfree(priv);
}
@@ -86,31 +80,18 @@ static void rtllib_ccmp_deinit(void *priv)
struct rtllib_ccmp_data *_priv = priv;
if (_priv && _priv->tfm)
- crypto_free_cipher((void *)_priv->tfm);
+ crypto_free_aead(_priv->tfm);
kfree(priv);
}
-static inline void xor_block(u8 *b, u8 *a, size_t len)
-{
- int i;
-
- for (i = 0; i < len; i++)
- b[i] ^= a[i];
-}
-
-
-
-static void ccmp_init_blocks(struct crypto_tfm *tfm,
- struct rtllib_hdr_4addr *hdr,
- u8 *pn, size_t dlen, u8 *b0, u8 *auth,
- u8 *s0)
+static int ccmp_init_iv_and_aad(struct rtllib_hdr_4addr *hdr,
+ u8 *pn, u8 *iv, u8 *aad)
{
u8 *pos, qc = 0;
size_t aad_len;
u16 fc;
int a4_included, qc_included;
- u8 aad[2 * AES_BLOCK_LEN];
fc = le16_to_cpu(hdr->frame_ctl);
a4_included = ((fc & (RTLLIB_FCTL_TODS | RTLLIB_FCTL_FROMDS)) ==
@@ -128,18 +109,19 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm,
qc = *pos & 0x0f;
aad_len += 2;
}
- /* CCM Initial Block:
- * Flag (Include authentication header, M=3 (8-octet MIC),
- * L=1 (2-octet Dlen))
- * Nonce: 0x00 | A2 | PN
- * Dlen
+ /* In CCM, the initial vectors (IV) used for CTR mode encryption and CBC
+ * mode authentication are not allowed to collide, yet both are derived
+ * from the same vector. We only set L := 1 here to indicate that the
+ * data size can be represented in (L+1) bytes. The CCM layer will take
+ * care of storing the data length in the top (L+1) bytes and setting
+ * and clearing the other bits as is required to derive the two IVs.
*/
- b0[0] = 0x59;
- b0[1] = qc;
- memcpy(b0 + 2, hdr->addr2, ETH_ALEN);
- memcpy(b0 + 8, pn, CCMP_PN_LEN);
- b0[14] = (dlen >> 8) & 0xff;
- b0[15] = dlen & 0xff;
+ iv[0] = 0x1;
+
+ /* Nonce: QC | A2 | PN */
+ iv[1] = qc;
+ memcpy(iv + 2, hdr->addr2, ETH_ALEN);
+ memcpy(iv + 8, pn, CCMP_PN_LEN);
/* AAD:
* FC with bits 4..6 and 11..13 masked to zero; 14 is always one
@@ -149,31 +131,21 @@ static void ccmp_init_blocks(struct crypto_tfm *tfm,
* QC (if present)
*/
pos = (u8 *) hdr;
- aad[0] = 0; /* aad_len >> 8 */
- aad[1] = aad_len & 0xff;
- aad[2] = pos[0] & 0x8f;
- aad[3] = pos[1] & 0xc7;
- memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN);
+ aad[0] = pos[0] & 0x8f;
+ aad[1] = pos[1] & 0xc7;
+ memcpy(aad + 2, hdr->addr1, 3 * ETH_ALEN);
pos = (u8 *) &hdr->seq_ctl;
- aad[22] = pos[0] & 0x0f;
- aad[23] = 0; /* all bits masked */
- memset(aad + 24, 0, 8);
+ aad[20] = pos[0] & 0x0f;
+ aad[21] = 0; /* all bits masked */
+ memset(aad + 22, 0, 8);
if (a4_included)
- memcpy(aad + 24, hdr->addr4, ETH_ALEN);
+ memcpy(aad + 22, hdr->addr4, ETH_ALEN);
if (qc_included) {
- aad[a4_included ? 30 : 24] = qc;
+ aad[a4_included ? 28 : 22] = qc;
/* rest of QC masked */
}
- /* Start with the first block and AAD */
- rtllib_ccmp_aes_encrypt(tfm, b0, auth);
- xor_block(auth, aad, AES_BLOCK_LEN);
- rtllib_ccmp_aes_encrypt(tfm, auth, auth);
- xor_block(auth, &aad[AES_BLOCK_LEN], AES_BLOCK_LEN);
- rtllib_ccmp_aes_encrypt(tfm, auth, auth);
- b0[0] &= 0x07;
- b0[14] = b0[15] = 0;
- rtllib_ccmp_aes_encrypt(tfm, b0, s0);
+ return aad_len;
}
@@ -213,40 +185,37 @@ static int rtllib_ccmp_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
*pos++ = key->tx_pn[1];
*pos++ = key->tx_pn[0];
-
hdr = (struct rtllib_hdr_4addr *) skb->data;
if (!tcb_desc->bHwSec) {
- int blocks, last, len;
- u8 *mic;
- u8 *b0 = key->tx_b0;
- u8 *b = key->tx_b;
- u8 *e = key->tx_e;
- u8 *s0 = key->tx_s0;
+ struct aead_request *req;
+ struct scatterlist sg[2];
+ u8 *aad = key->tx_aad;
+ u8 iv[AES_BLOCK_LEN];
+ int aad_len, ret;
+ int data_len = skb->len - hdr_len - CCMP_HDR_LEN;
- mic = skb_put(skb, CCMP_MIC_LEN);
+ req = aead_request_alloc(key->tfm, GFP_ATOMIC);
+ if (!req)
+ return -ENOMEM;
- ccmp_init_blocks(key->tfm, hdr, key->tx_pn, data_len,
- b0, b, s0);
+ aad_len = ccmp_init_iv_and_aad(hdr, key->tx_pn, iv, aad);
- blocks = DIV_ROUND_UP(data_len, AES_BLOCK_LEN);
- last = data_len % AES_BLOCK_LEN;
+ skb_put(skb, CCMP_MIC_LEN);
+ sg_init_table(sg, 2);
+ sg_set_buf(&sg[0], aad, aad_len);
+ sg_set_buf(&sg[1], skb->data + hdr_len + CCMP_HDR_LEN,
+ data_len + CCMP_MIC_LEN);
- for (i = 1; i <= blocks; i++) {
- len = (i == blocks && last) ? last : AES_BLOCK_LEN;
- /* Authentication */
- xor_block(b, pos, len);
- rtllib_ccmp_aes_encrypt(key->tfm, b, b);
- /* Encryption, with counter */
- b0[14] = (i >> 8) & 0xff;
- b0[15] = i & 0xff;
- rtllib_ccmp_aes_encrypt(key->tfm, b0, e);
- xor_block(pos, e, len);
- pos += len;
- }
+ aead_request_set_callback(req, 0, NULL, NULL);
+ aead_request_set_ad(req, aad_len);
+ aead_request_set_crypt(req, sg, sg, data_len, iv);
- for (i = 0; i < CCMP_MIC_LEN; i++)
- mic[i] = b[i] ^ s0[i];
+ ret = crypto_aead_encrypt(req);
+ aead_request_free(req);
+
+ return ret;
}
+
return 0;
}
@@ -302,35 +271,31 @@ static int rtllib_ccmp_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
return -4;
}
if (!tcb_desc->bHwSec) {
- size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN -
- CCMP_MIC_LEN;
- u8 *mic = skb->data + skb->len - CCMP_MIC_LEN;
- u8 *b0 = key->rx_b0;
- u8 *b = key->rx_b;
- u8 *a = key->rx_a;
- int i, blocks, last, len;
+ size_t data_len = skb->len - hdr_len - CCMP_HDR_LEN;
+ struct aead_request *req;
+ struct scatterlist sg[2];
+ u8 *aad = key->rx_aad;
+ u8 iv[AES_BLOCK_LEN];
+ int aad_len, ret;
+ req = aead_request_alloc(key->tfm, GFP_ATOMIC);
+ if(!req)
+ return -ENOMEM;
- ccmp_init_blocks(key->tfm, hdr, pn, data_len, b0, a, b);
- xor_block(mic, b, CCMP_MIC_LEN);
+ aad_len = ccmp_init_iv_and_aad(hdr, pn, iv, aad);
- blocks = DIV_ROUND_UP(data_len, AES_BLOCK_LEN);
- last = data_len % AES_BLOCK_LEN;
+ sg_init_table(sg, 2);
+ sg_set_buf(&sg[0], aad, aad_len);
+ sg_set_buf(&sg[1], pos, data_len);
- for (i = 1; i <= blocks; i++) {
- len = (i == blocks && last) ? last : AES_BLOCK_LEN;
- /* Decrypt, with counter */
- b0[14] = (i >> 8) & 0xff;
- b0[15] = i & 0xff;
- rtllib_ccmp_aes_encrypt(key->tfm, b0, b);
- xor_block(pos, b, len);
- /* Authentication */
- xor_block(a, pos, len);
- rtllib_ccmp_aes_encrypt(key->tfm, a, a);
- pos += len;
- }
+ aead_request_set_callback(req, 0, NULL, NULL);
+ aead_request_set_ad(req, aad_len);
+ aead_request_set_crypt(req, sg, sg, data_len, iv);
- if (memcmp(mic, a, CCMP_MIC_LEN) != 0) {
+ ret = crypto_aead_decrypt(req);
+ aead_request_free(req);
+
+ if (ret) {
if (net_ratelimit()) {
pr_debug("CCMP: decrypt failed: STA= %pM\n",
hdr->addr2);
@@ -354,7 +319,7 @@ static int rtllib_ccmp_set_key(void *key, int len, u8 *seq, void *priv)
{
struct rtllib_ccmp_data *data = priv;
int keyidx;
- struct crypto_tfm *tfm = data->tfm;
+ struct crypto_aead *tfm = data->tfm;
keyidx = data->key_idx;
memset(data, 0, sizeof(*data));
@@ -371,7 +336,9 @@ static int rtllib_ccmp_set_key(void *key, int len, u8 *seq, void *priv)
data->rx_pn[4] = seq[1];
data->rx_pn[5] = seq[0];
}
- crypto_cipher_setkey((void *)data->tfm, data->key, CCMP_TK_LEN);
+ if (crypto_aead_setauthsize(data->tfm, CCMP_MIC_LEN) ||
+ crypto_aead_setkey(data->tfm, data->key, CCMP_TK_LEN))
+ return -1;
} else if (len == 0) {
data->key_set = 0;
} else {
--
2.20.1
^ permalink raw reply related
* [PATCH 0/2] Use ccm(aes) aead transform in staging drivers
From: Christina Quast @ 2019-08-16 6:59 UTC (permalink / raw)
To: ard.biesheuvel
Cc: Christina Quast, Greg Kroah-Hartman, Payal Kshirsagar,
Eric Biggers, Herbert Xu, devel, linux-kernel, Anushka Shukla,
Bartlomiej Zolnierkiewicz, Zach Turner, linux-wireless,
Johannes Berg, David S. Miller, linux-crypto
Use ccm(aes) aead transform instead of invoking the AES block cipher
block by block.
Christina Quast (2):
staging: rtl8192u: ieee80211: ieee80211_crypt_ccmp.c: Use crypto API
ccm(aes)
staging: rtl8192e: rtllib_crypt_ccmp.c: Use crypto API ccm(aes)
drivers/staging/rtl8192e/Kconfig | 1 +
drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 187 ++++++++----------
drivers/staging/rtl8192u/Kconfig | 2 +
.../rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 187 ++++++++----------
4 files changed, 159 insertions(+), 218 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
From: Jian-Hong Pan @ 2019-08-16 6:31 UTC (permalink / raw)
To: Yan-Hsuan Chuang, Kalle Valo, David S . Miller
Cc: linux-wireless, netdev, linux-kernel, linux, Jian-Hong Pan
There is a mass of jobs between spin lock and unlock in the hardware
IRQ which will occupy much time originally. To make system work more
efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
reduce the time in hardware IRQ.
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
---
drivers/net/wireless/realtek/rtw88/pci.c | 36 +++++++++++++++++++-----
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 00ef229552d5..355606b167c6 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -866,12 +866,29 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
{
struct rtw_dev *rtwdev = dev;
struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
- u32 irq_status[4];
+ unsigned long flags;
- spin_lock(&rtwpci->irq_lock);
+ spin_lock_irqsave(&rtwpci->irq_lock, flags);
if (!rtwpci->irq_enabled)
goto out;
+ /* disable RTW PCI interrupt to avoid more interrupts before the end of
+ * thread function
+ */
+ rtw_pci_disable_interrupt(rtwdev, rtwpci);
+out:
+ spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
+{
+ struct rtw_dev *rtwdev = dev;
+ struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
+ unsigned long flags;
+ u32 irq_status[4];
+
rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
if (irq_status[0] & IMR_MGNTDOK)
@@ -891,8 +908,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq, void *dev)
if (irq_status[0] & IMR_ROK)
rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
-out:
- spin_unlock(&rtwpci->irq_lock);
+ /* all of the jobs for this interrupt have been done */
+ spin_lock_irqsave(&rtwpci->irq_lock, flags);
+ if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
+ rtw_pci_enable_interrupt(rtwdev, rtwpci);
+ spin_unlock_irqrestore(&rtwpci->irq_lock, flags);
return IRQ_HANDLED;
}
@@ -1152,8 +1172,10 @@ static int rtw_pci_probe(struct pci_dev *pdev,
goto err_destroy_pci;
}
- ret = request_irq(pdev->irq, &rtw_pci_interrupt_handler,
- IRQF_SHARED, KBUILD_MODNAME, rtwdev);
+ ret = devm_request_threaded_irq(rtwdev->dev, pdev->irq,
+ rtw_pci_interrupt_handler,
+ rtw_pci_interrupt_threadfn,
+ IRQF_SHARED, KBUILD_MODNAME, rtwdev);
if (ret) {
ieee80211_unregister_hw(hw);
goto err_destroy_pci;
@@ -1192,7 +1214,7 @@ static void rtw_pci_remove(struct pci_dev *pdev)
rtw_pci_disable_interrupt(rtwdev, rtwpci);
rtw_pci_destroy(rtwdev, pdev);
rtw_pci_declaim(rtwdev, pdev);
- free_irq(rtwpci->pdev->irq, rtwdev);
+ devm_free_irq(rtwdev->dev, rtwpci->pdev->irq, rtwdev);
rtw_core_deinit(rtwdev);
ieee80211_free_hw(hw);
}
--
2.20.1
^ permalink raw reply related
* Re: Implementing Mikrotik IE
From: Sebastian Gottschall @ 2019-08-16 4:07 UTC (permalink / raw)
To: Josef Miegl, linux-wireless
In-Reply-To: <20190815152844.k5mmddvbwrohkzr6@pepin-laptop.localdomain>
Hello
Since i already have done this for dd-wrt for mac80211 i can tell you,
its not easy but possible. the most easy way for broadcasting a custom IE
is just adding a custom IE with its properties to the hostapd
configuration. it does allow to set such properties
so you dont need to change anything in mac80211 which requires some evil
hacks
Am 15.08.2019 um 17:28 schrieb Josef Miegl:
> I've been trying to implement Mikrotik IE. It is a vendor IE that
> carries stuff like radio name. Even though it is Mikrotik specific, UBNT
> has a patch for madwifi:
> https://github.com/jhairtt/ubnt-hal-0.7.379/blob/master/patches/madwifi-dfs-r3319-20080201/074-mtik-ie.patch
>
> The IE is sent in beacon and assoc/reassoc frames. I think the correct
> place for this is mac80211, but I'm not sure how should I expose a
> switch to this functionality. Is there something like ioctl, or do I have
> to implement a switch in nl80211, then in cfg80211 and then finally in
> mac80211?
>
> Any advice is greatly appreciated.
>
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: add assoc-at support.
From: Sebastian Gottschall @ 2019-08-16 4:09 UTC (permalink / raw)
To: greearb, linux-wireless; +Cc: johannes
In-Reply-To: <20190809174656.20872-2-greearb@candelatech.com>
is this feature neccessary? we already have the information of the assoc
duration time. so its easy to calculate the assoc timestamp using the
current time without any patch
do i miss something here?
Am 09.08.2019 um 19:46 schrieb greearb@candelatech.com:
> From: Ben Greear <greearb@candelatech.com>
>
> Report timestamp for when sta becomes associated.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> net/mac80211/sta_info.c | 3 +++
> net/mac80211/sta_info.h | 2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
> index cd88c8872372..f0820f058b5f 100644
> --- a/net/mac80211/sta_info.c
> +++ b/net/mac80211/sta_info.c
> @@ -1995,6 +1995,7 @@ int sta_info_move_state(struct sta_info *sta,
> case IEEE80211_STA_ASSOC:
> if (sta->sta_state == IEEE80211_STA_AUTH) {
> set_bit(WLAN_STA_ASSOC, &sta->_flags);
> + sta->assoc_at_ms = ktime_to_ms(ktime_get_real());
> ieee80211_recalc_min_chandef(sta->sdata);
> if (!sta->sta.support_p2p_ps)
> ieee80211_recalc_p2p_go_ps_allowed(sta->sdata);
> @@ -2224,6 +2225,7 @@ void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo,
> BIT_ULL(NL80211_STA_INFO_STA_FLAGS) |
> BIT_ULL(NL80211_STA_INFO_BSS_PARAM) |
> BIT_ULL(NL80211_STA_INFO_CONNECTED_TIME) |
> + BIT_ULL(NL80211_STA_INFO_ASSOC_AT_MS) |
> BIT_ULL(NL80211_STA_INFO_RX_DROP_MISC);
>
> if (sdata->vif.type == NL80211_IFTYPE_STATION) {
> @@ -2232,6 +2234,7 @@ void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo,
> }
>
> sinfo->connected_time = ktime_get_seconds() - sta->last_connected;
> + sinfo->assoc_at_ms = sta->assoc_at_ms;
> sinfo->inactive_time =
> jiffies_to_msecs(jiffies - ieee80211_sta_last_active(sta));
>
> diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
> index bb02d5fac7ba..906b11acb0e8 100644
> --- a/net/mac80211/sta_info.h
> +++ b/net/mac80211/sta_info.h
> @@ -468,6 +468,7 @@ struct ieee80211_sta_rx_stats {
> * the station when it leaves powersave or polls for frames
> * @driver_buffered_tids: bitmap of TIDs the driver has data buffered on
> * @txq_buffered_tids: bitmap of TIDs that mac80211 has txq data buffered on
> + * @assoc_at_ms: time (in ms) of last association
> * @last_connected: time (in seconds) when a station got connected
> * @last_seq_ctrl: last received seq/frag number from this STA (per TID
> * plus one for non-QoS frames)
> @@ -565,6 +566,7 @@ struct sta_info {
> unsigned long driver_buffered_tids;
> unsigned long txq_buffered_tids;
>
> + unsigned long assoc_at_ms;
> long last_connected;
>
> /* Updated from RX path only, no locking requirements */
^ permalink raw reply
* [PATCH] airo: fix memory leaks
From: Wenwen Wang @ 2019-08-16 3:50 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kalle Valo, David S. Miller, Herbert Xu, Dan Carpenter,
Eric Biggers, Ard Biesheuvel,
open list:NETWORKING DRIVERS (WIRELESS),
open list:NETWORKING DRIVERS, open list
In proc_BSSList_open(), 'file->private_data' is allocated through kzalloc()
and 'data->rbuffer' is allocated through kmalloc(). In the following
execution, if an error occurs, they are not deallocated, leading to memory
leaks. To fix this issue, free the allocated memory regions before
returning the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/wireless/cisco/airo.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c
index 9342ffb..f43c065 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -5441,11 +5441,18 @@ static int proc_BSSList_open( struct inode *inode, struct file *file ) {
Cmd cmd;
Resp rsp;
- if (ai->flags & FLAG_RADIO_MASK) return -ENETDOWN;
+ if (ai->flags & FLAG_RADIO_MASK) {
+ kfree(data->rbuffer);
+ kfree(file->private_data);
+ return -ENETDOWN;
+ }
memset(&cmd, 0, sizeof(cmd));
cmd.cmd=CMD_LISTBSS;
- if (down_interruptible(&ai->sem))
+ if (down_interruptible(&ai->sem)) {
+ kfree(data->rbuffer);
+ kfree(file->private_data);
return -ERESTARTSYS;
+ }
issuecommand(ai, &cmd, &rsp);
up(&ai->sem);
data->readlen = 0;
--
2.7.4
^ permalink raw reply related
* RE: [PATCH v3 2/3] rtw88: enclose c2h cmd handle with mutex
From: Tony Chuang @ 2019-08-16 2:45 UTC (permalink / raw)
To: Brian Norris; +Cc: Kalle Valo, linux-wireless, Stanislaw Gruszka
In-Reply-To: <CA+ASDXPJiNTXAihzohT06RS57gkJU9Q-u3kpp0piJP-3U1miFw@mail.gmail.com>
> I understand this is already queued up, but I still have a question:
>
> On Wed, Jul 31, 2019 at 5:23 AM <yhchuang@realtek.com> wrote:
> > C2H commands that cannot be handled in IRQ context should
> > be protected by rtwdev->mutex. Because they might have a
> > sequece of hardware operations that does not want to be
> > interfered.
>
> Can you elaborate on what interference you're looking at, exactly? I'm
> not a big fan of defensive addition of global locks, and this
> particular mutex isn't very targeted. It claims to be for mac80211
> callbacks, but you use it in quite a few places (some of which clearly
> don't make sense), and many of them are not related to mac80211
> callbacks AFAICT.
Basically it must protect rtwdev itself for mac80211 callbacks, but
work queue also should be protected, as work queue could be interfered
by mac80211 callbacks IIUC. And most of the time what I want to
protect is the "hardware operations". I might implicitly binds those
register read/write(s) with the rtwdev struct.
I think the problem here is I should give a better comment to better
describe the usage of the mutex. And I also want to keep it short.
>
> To the contrary: this handler is called from the mac80211 work queue,
> which is ordered and therefore shouldn't be getting "interrupted"
> (e.g., conflicting commands). But then, you added the 'irqsafe'
> command, which gets run from the ISR...and doesn't hold this lock,
> obviously.
C2H work queue will not interrupt each other, but mac80211 callbacks
could, as most of the functions are consist of a sequence of hardware
register operations. And I don't want to use I/O under ISR context,
so here to split the C2H commands.
>
> It may well be that you're correct here, but I'd like to see a better
> explanation for stuff like this. And maybe an update to the
> rtw_dev::mutex comments.
>
> Brian
>
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH v3 2/3] rtw88: enclose c2h cmd handle with mutex
From: Brian Norris @ 2019-08-15 21:11 UTC (permalink / raw)
To: Tony Chuang; +Cc: Kalle Valo, linux-wireless, Stanislaw Gruszka
In-Reply-To: <1564575767-27557-3-git-send-email-yhchuang@realtek.com>
I understand this is already queued up, but I still have a question:
On Wed, Jul 31, 2019 at 5:23 AM <yhchuang@realtek.com> wrote:
> C2H commands that cannot be handled in IRQ context should
> be protected by rtwdev->mutex. Because they might have a
> sequece of hardware operations that does not want to be
> interfered.
Can you elaborate on what interference you're looking at, exactly? I'm
not a big fan of defensive addition of global locks, and this
particular mutex isn't very targeted. It claims to be for mac80211
callbacks, but you use it in quite a few places (some of which clearly
don't make sense), and many of them are not related to mac80211
callbacks AFAICT.
To the contrary: this handler is called from the mac80211 work queue,
which is ordered and therefore shouldn't be getting "interrupted"
(e.g., conflicting commands). But then, you added the 'irqsafe'
command, which gets run from the ISR...and doesn't hold this lock,
obviously.
It may well be that you're correct here, but I'd like to see a better
explanation for stuff like this. And maybe an update to the
rtw_dev::mutex comments.
Brian
^ permalink raw reply
* [PATCH] ath10k: add cleanup in ath10k_sta_state()
From: Wenwen Wang @ 2019-08-15 21:04 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kalle Valo, David S. Miller,
open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER,
open list:NETWORKING DRIVERS (WIRELESS),
open list:NETWORKING DRIVERS, open list
If 'sta->tdls' is false, no cleanup is executed, leading to memory/resource
leaks, e.g., 'arsta->tx_stats'. To fix this issue, perform cleanup before
go to the 'exit' label.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/wireless/ath/ath10k/mac.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0606416..f99e6d2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6548,8 +6548,12 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
spin_unlock_bh(&ar->data_lock);
- if (!sta->tdls)
+ if (!sta->tdls) {
+ ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
+ ath10k_mac_dec_num_stations(arvif, sta);
+ kfree(arsta->tx_stats);
goto exit;
+ }
ret = ath10k_wmi_update_fw_tdls_state(ar, arvif->vdev_id,
WMI_TDLS_ENABLE_ACTIVE);
--
2.7.4
^ permalink raw reply related
* Re: [RFC 0/1] Allow MAC change on up interface
From: Jeff Johnson @ 2019-08-15 20:48 UTC (permalink / raw)
To: James Prestwood; +Cc: linux-wireless, linux-wireless-owner
In-Reply-To: <20190815185702.30937-1-prestwoj@gmail.com>
On 2019-08-15 11:57, James Prestwood wrote:
> - Adds a new NL80211_ATTR for including a "random mac" to
> CMD_CONNECT. This MAC is passed down the stack and gets set to
> the net_device's address.
My initial reaction is that I'd avoid using the term "random". For some
use cases the address may truly be random, but for other use cases it
may be derived, perhaps in an AP-specific manner. Other terms which may
be more appropriate are "spoofed mac", "administered mac", etc.
It is a shame that due to backward compatibility we can't use
NL80211_ATTR_MAC while shifting the current usage over to using
NL80211_ATTR_BSSID.
^ permalink raw reply
* Re: [PATCH v3 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Brian Norris @ 2019-08-15 20:25 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, Larry Finger,
David Laight, Christoph Hellwig, linux-wireless,
<netdev@vger.kernel.org>, Linux Kernel, linux, Daniel Drake,
stable
In-Reply-To: <20190710083825.7115-1-jian-hong@endlessm.com>
Hi all,
I realize this already is merged, and it had some previous review
comments that led to the decisions in this patch, but I'd still like
to ask here, where I think I'm reaching the relevant parties:
On Wed, Jul 10, 2019 at 1:43 AM Jian-Hong Pan <jian-hong@endlessm.com> wrote:
...
> This patch allocates a new, data-sized skb first in RX ISR. After
> copying the data in, we pass it to the upper layers. However, if skb
> allocation fails, we effectively drop the frame. In both cases, the
> original, full size ring skb is reused.
>
> In addition, by fixing the kernel crash, the RX routine should now
> generally behave better under low memory conditions.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: <stable@vger.kernel.org>
> ---
> v2:
> - Allocate new data-sized skb and put data into it, then pass it to
> mac80211. Reuse the original skb in RX ring by DMA sync.
Is it really wise to force an extra memcpy() for *every* delivery?
Isn't there some other strategy that could be used to properly handle
low-memory scenarios while still passing the original buffer up to
higher layers most of the time? Or is it really so bad to keep
re-allocating RTK_PCI_RX_BUF_SIZE (>8KB) of contiguous memory, to
re-fill the RX ring? And if that is so bad, can we reduce the
requirement for contiguous memory instead? (e.g., keep with smaller
buffers, and perform aggregation / scatter-gather only for frames that
are really larger?)
Anyway, that's mostly a long-term thought, as this patch is good for
fixing the important memory errors, even if it's not necessarily the
ideal solution.
Regards,
Brian
^ permalink raw reply
* BUG: atk9k/mac80211 CONTROL_PORT_FRAME processing + MFP
From: Denis Kenzior @ 2019-08-15 19:10 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
We're getting reports of weird behavior on ath9k/mac80211 devices when
CONTROL_PORT_FRAME support is used. iwlwifi, works fine under the same
circumstances. If CONTROL_PORT_FRAME is disabled and the old legacy PAE
transport is used, everything works fine.
The short version:
- We Connect with MFP enabled
- Handshake packet 1 & 2 is exchanged
- Handshake packet 3 is received & reply sent
- Keys are set
- AP never receives our packet 4, or the card drops it locally
- Subsequent retransmissions are sent un-encrypted by the AP and are
probably sent encrypted (via MFP) by mac80211. Since the driver never
sets NO_ENCRYPT flag, userspace has no knowledge to try and send the
reply un-encrypted.
Here's a log (some parts are removed for brevity, but if someone wants
the full log, I can provide this as well):
< Request: Connect (0x2e) len 160 [ack]
1565892849.337243
Interface Index: 13 (0x0000000d)
Wiphy Frequency: 5805 (0x000016ad)
MAC Address 10:C3:7B:54:74:D4
SSID: len 9
Auth Type: 0 (0x00000000)
Privacy: true
Interface Socket Owner: true
Cipher Suites Pairwise:
CCMP (00:0f:ac) suite 04
Cipher Suite Group: CCMP (00:0f:ac) suite 04
Use MFP: 1 (0x00000001)
AKM Suites:
PSK; RSNA PSK (00:0f:ac) suite 02
WPA Versions: 2 (0x00000002)
Control Port: true
Control Port over NL80211: true
Use RRM: true
Information Elements: len 41
RSN:
Group Data Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
Pairwise Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
AKM Suite: len 4
PSK; RSNA PSK (00:0f:ac) suite 02
RSN capabilities: bits 2 - 3: 1 replay counter per PTKSA
RSN capabilities: bits 4 - 5: 1 replay counter per GTKSA
RSN capabilities: bit 7: Management Frame Protection Capable
01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f
................
ac 02 80 00 ....
RM Enabled Capabilities: len 5
Operating Channel Max Measurement Duration: 0
Non-Operating Channel Max Measurement Duration: 0
Measurement Pilot Capability: 0
00 00 00 00 00 .....
Extended Capabilities: len 10
Capability: bit 62: Opmode Notification
00 00 00 00 00 00 00 40 00 00 .......@..
> Event: New Station (0x13) len 32
1565892851.673886
Interface Index: 13 (0x0000000d)
MAC Address 10:C3:7B:54:74:D4
Generation: 5 (0x00000005)
Station Info: len 0
> Response: Connect (0x2e) len 4 [0x100]
1565892851.673971
Status: Success (0)
> Event: Authenticate (0x25) len 64
1565892851.676737
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
Frame: len 41
<snip>
Here comes the Handshake packet 1 from the AP. Why the hell is it here
prior to Authenticate ? But whatever ;)
> Event: Control Port Frame (0x81) len 176
1565892851.686055
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
Wireless Device: 4294967299 (0x0000000100000003)
MAC Address 10:C3:7B:54:74:D4
Control Port Ethertype: 34958 (0x888e)
Frame: len 121
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 117
Descriptor Type: 2
Key MIC: false
Secure: false
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: true
Key Length: 16
Key Replay Counter: 0
Key NONCE
e4 5b 1d 98 fd db 54 ae 54 98 fc 39 69 f5 bc 0b
.[....T.T..9i...
f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d de
....PC.m'.....m.
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key Data: len 22
Vendor specific: len 20
IEEE 802.11 (00:0f:ac) type: 04
PMKID KDE
00 0f ac 04 d9 81 f4 29 57 31 7e ad 33 57 b8 af
.......)W1~.3W..
c7 a7 40 8f ..@.
02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 ...u............
00 e4 5b 1d 98 fd db 54 ae 54 98 fc 39 69 f5 bc ..[....T.T..9i..
0b f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d .....PC.m'.....m
de 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 16 dd 14 00 0f ac 04 d9 81 f4 29 57 31 7e ............)W1~
ad 33 57 b8 af c7 a7 40 8f .3W....@.
> Event: Associate (0x26) len 292
1565892851.752271
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
Frame: len 152
<snip>
> Event: Connect (0x2e) len 272
1565892851.752302
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
MAC Address 10:C3:7B:54:74:D4
Status Code: 0 (0x0000)
Request IE: len 103
SSID: <snip>
Supported rates:
6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit/s
0c 12 18 24 30 48 60 6c ...$0H`l
Tag 33: len 2
00 1e ..
RSN:
Group Data Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
Pairwise Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
AKM Suite: len 4
PSK; RSNA PSK (00:0f:ac) suite 02
RSN capabilities: bits 2 - 3: 1 replay counter per PTKSA
RSN capabilities: bits 4 - 5: 1 replay counter per GTKSA
RSN capabilities: bit 7: Management Frame Protection Capable
01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f
................
ac 02 80 00 ....
RM Enabled Capabilities: len 5
Operating Channel Max Measurement Duration: 0
Non-Operating Channel Max Measurement Duration: 0
Measurement Pilot Capability: 0
00 00 00 00 00 .....
HT Capabilities: len 26
HT Capabilities Info: bit 1: Supported Channel Width Set
HT Capabilities Info: bits 2-3: Disabled
HT Capabilities Info: bit 6: Short GI for 40Mhz
HT Capabilities Info: bit 7: Tx STBC
HT Capabilities Info: bits 8-9: One spatial stream
HT Capabilities Info: bit 12: DSSS/CCK Mode in 40Mhz
A-MPDU Parameters: Maximum A-MPDU Length Exponent: 3
A-MPDU Parameters: Minimum MPDU Start Spacing: 8 us
Supported MCS: MCS 0
Supported MCS: MCS 1
Supported MCS: MCS 2
Supported MCS: MCS 3
Supported MCS: MCS 4
Supported MCS: MCS 5
Supported MCS: MCS 6
Supported MCS: MCS 7
Supported MCS: MCS 8
Supported MCS: MCS 9
Supported MCS: MCS 10
Supported MCS: MCS 11
Supported MCS: MCS 12
Supported MCS: MCS 13
Supported MCS: MCS 14
Supported MCS: MCS 15
MCS Set: bit 96: Tx MCS set defined
HT Extended Capabilities: PCO: supported
HT Extended Capabilities: MCS Feedback: No feedback
HT Extended Capabilities: +HTC: not supported
HT Extended Capabilities: RD Responder: not supported
ce 11 1b ff ff 00 00 00 00 00 00 00 00 00 00 01
................
00 00 00 00 00 00 00 00 00 00 ..........
Extended Capabilities: len 10
Capability: bit 62: Opmode Notification
00 00 00 00 00 00 00 40 00 00 .......@..
Vendor specific: len 7
Microsoft (00:50:f2) type: 02
00 50 f2 02 00 01 00 .P.....
Response IE: len 122
Supported rates:
6.0(B) 9.0 12.0(B) 18.0 24.0(B) 36.0 48.0 54.0 Mbit/s
8c 12 98 24 b0 48 60 6c ...$.H`l
Tag 53: len 1
00 .
Tag 65: len 1
00 .
RM Enabled Capabilities: len 5
Enabled: bit 1: Neighbor Report
Enabled: bit 4: Beacon Passive Measurement
Enabled: bit 5: Beacon Active Measurement
Enabled: bit 6: Beacon Table Measurement
Enabled: bit 11: Statistics Measurement
Enabled: bit 16: AP Channel Report
Operating Channel Max Measurement Duration: 0
Non-Operating Channel Max Measurement Duration: 0
Measurement Pilot Capability: 0
72 08 01 00 00 r....
HT Capabilities: len 26
HT Capabilities Info: bit 0: LDPC Coding Capability
HT Capabilities Info: bit 1: Supported Channel Width Set
HT Capabilities Info: bits 2-3: Disabled
HT Capabilities Info: bit 5: Short GI for 20Mhz
HT Capabilities Info: bit 6: Short GI for 40Mhz
HT Capabilities Info: bit 7: Tx STBC
HT Capabilities Info: bits 8-9: One spatial stream
HT Capabilities Info: bit 11: Maximum A-MSDU Length
A-MPDU Parameters: Maximum A-MPDU Length Exponent: 3
A-MPDU Parameters: Minimum MPDU Start Spacing: 4 us
Supported MCS: MCS 0
Supported MCS: MCS 1
Supported MCS: MCS 2
Supported MCS: MCS 3
Supported MCS: MCS 4
Supported MCS: MCS 5
Supported MCS: MCS 6
Supported MCS: MCS 7
Supported MCS: MCS 8
Supported MCS: MCS 9
Supported MCS: MCS 10
Supported MCS: MCS 11
Supported MCS: MCS 12
Supported MCS: MCS 13
Supported MCS: MCS 14
Supported MCS: MCS 15
HT Extended Capabilities: PCO: supported
HT Extended Capabilities: MCS Feedback: No feedback
HT Extended Capabilities: +HTC: not supported
HT Extended Capabilities: RD Responder: not supported
ef 09 17 ff ff 00 00 00 00 00 00 00 00 00 00 00
................
00 00 00 00 00 00 00 00 00 00 ..........
HT Operation:
Primary channel 161
Information: Secondary Channel Offset: below primary channel
Information: Channel width: bit 2: Any supported channel width
Information: bit 3: RIFS permitted
Information: HT Protection: bits 8 - 9: 20 MHz protection
mode
Information: bit 10: Non-greenfield HT STAs present
Information: bit 12: OBSS non-HT STAs present
a1 0f 16 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00 00 00 00 00 00 ......
Extended Capabilities: len 8
Capability: bit 2: Extended channel switching
Capability: bit 19: BSS transition
Capability: bit 62: Opmode Notification
04 00 08 00 00 00 00 40 .......@
Vendor specific: len 9
Broadcom (00:10:18) type: 02
00 10 18 02 01 00 1c 00 00 .........
Vendor specific: len 24
Microsoft (00:50:f2) type: 02
00 50 f2 02 01 01 84 00 03 a4 00 00 27 a4 00 00
.P..........'...
42 43 5e 00 62 32 2f 00 BC^.b2/.
< Request: Control Port Frame (0x81) len 156 [ack]
1565892851.752751
Interface Index: 13 (0x0000000d)
Frame: len 121
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 117
Descriptor Type: 2
Key MIC: true
Secure: false
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: false
Key Length: 0
Key Replay Counter: 0
Key NONCE
74 29 cc 1b 86 49 4c 4d d7 cf e8 54 70 ec 67 ee
t)...ILM...Tp.g.
ea 15 f5 28 5c e7 46 ff cc c2 71 9b 0b 79 f1 d7
...(\.F...q..y..
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
2a 9f bc 4a 3f 53 c4 68 a5 1f 86 3e 56 ea bd 3c
*..J?S.h...>V..<
Key Data: len 22
RSN:
Group Data Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
Pairwise Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
AKM Suite: len 4
PSK; RSNA PSK (00:0f:ac) suite 02
RSN capabilities: bits 2 - 3: 1 replay counter per PTKSA
RSN capabilities: bits 4 - 5: 1 replay counter per GTKSA
RSN capabilities: bit 7: Management Frame Protection
Capable
01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f
................
ac 02 80 00 ....
02 03 00 75 02 01 0a 00 00 00 00 00 00 00 00 00 ...u............
00 74 29 cc 1b 86 49 4c 4d d7 cf e8 54 70 ec 67 .t)...ILM...Tp.g
ee ea 15 f5 28 5c e7 46 ff cc c2 71 9b 0b 79 f1 ....(\.F...q..y.
d7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 2a 9f bc 4a 3f 53 c4 68 a5 1f 86 3e 56 ea bd .*..J?S.h...>V..
3c 00 16 30 14 01 00 00 0f ac 04 01 00 00 0f ac <..0............
04 01 00 00 0f ac 02 80 00 .........
Control Port Ethertype: 34958 (0x888e)
MAC Address 10:C3:7B:54:74:D4
> Response: Control Port Frame (0x81) len 4 [0x100]
1565892851.755532
Status: Success (0)
Handshake packet 3:
> Event: Control Port Frame (0x81) len 240
1565892851.766837
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
Wireless Device: 4294967299 (0x0000000100000003)
MAC Address 10:C3:7B:54:74:D4
Control Port Ethertype: 34958 (0x888e)
Frame: len 187
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 183
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: true
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: true
Key ACK: true
Key Length: 16
Key Replay Counter: 1
Key NONCE
e4 5b 1d 98 fd db 54 ae 54 98 fc 39 69 f5 bc 0b
.[....T.T..9i...
f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d de
....PC.m'.....m.
Key IV
f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d df
....PC.m'.....m.
Key RSC
83 01 00 00 00 00 00 00 ........
Key MIC Data
01 20 2e 3f 3c 26 03 cc 2f c8 eb 98 e0 ef 75 3d .
.?<&../.....u=
Key Data: len 88
78 d0 96 78 9f 2a 99 03 39 66 80 fd bd cf aa a5
x..x.*..9f......
6f 96 e2 bb 6b 95 51 e9 63 cd 69 17 7a 4a e2 f8
o...k.Q.c.i.zJ..
f6 b2 c4 f8 a0 08 8d b3 7d 1d ec d8 4a a1 60 33
........}...J.`3
e0 cb c0 14 26 d1 92 c4 70 91 6b ce a3 d2 11 5e
....&...p.k....^
99 90 65 22 49 e6 de 9f 01 02 e9 d4 53 37 2e 53
..e"I.......S7.S
6b f9 ab df d2 b4 8e 35 k......5
02 03 00 b7 02 13 ca 00 10 00 00 00 00 00 00 00 ................
01 e4 5b 1d 98 fd db 54 ae 54 98 fc 39 69 f5 bc ..[....T.T..9i..
0b f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d .....PC.m'.....m
de f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d .....PC.m'.....m
df 83 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 01 20 2e 3f 3c 26 03 cc 2f c8 eb 98 e0 ef 75 .. .?<&../.....u
3d 00 58 78 d0 96 78 9f 2a 99 03 39 66 80 fd bd =.Xx..x.*..9f...
cf aa a5 6f 96 e2 bb 6b 95 51 e9 63 cd 69 17 7a ...o...k.Q.c.i.z
4a e2 f8 f6 b2 c4 f8 a0 08 8d b3 7d 1d ec d8 4a J..........}...J
a1 60 33 e0 cb c0 14 26 d1 92 c4 70 91 6b ce a3 .`3....&...p.k..
d2 11 5e 99 90 65 22 49 e6 de 9f 01 02 e9 d4 53 ..^..e"I.......S
37 2e 53 6b f9 ab df d2 b4 8e 35 7.Sk......5
< Request: Control Port Frame (0x81) len 132 [ack]
1565892851.767264
Interface Index: 13 (0x0000000d)
Frame: len 99
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 95
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: false
Key Length: 0
Key Replay Counter: 1
Key NONCE
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
b4 fb b3 ed 13 55 92 b4 79 4d 69 77 64 0d 47 dd
.....U..yMiwd.G.
Key Data: len 0
02 03 00 5f 02 03 0a 00 00 00 00 00 00 00 00 00 ..._............
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 b4 fb b3 ed 13 55 92 b4 79 4d 69 77 64 0d 47 ......U..yMiwd.G
dd 00 00 ...
Control Port Ethertype: 34958 (0x888e)
MAC Address 10:C3:7B:54:74:D4
> Response: Control Port Frame (0x81) len 4 [0x100]
1565892851.767292
Status: Success (0)
So as you can see here, we process the handshake successfully, send the
Handshake packet 4/4 and proceed to setting keys:
< Request: New Key (0x0b) len 60 [ack]
1565892851.767323
Interface Index: 13 (0x0000000d)
Key: len 48
> Response: New Key (0x0b) len 4 [0x100]
1565892851.775960
Status: Success (0)
< Request: New Key (0x0b) len 60 [ack]
1565892851.775989
Interface Index: 13 (0x0000000d)
Key: len 48
> Response: New Key (0x0b) len 4 [0x100]
1565892851.776091
Status: Success (0)
< Request: New Key (0x0b) len 56 [ack]
1565892851.776103
Key Data: len 16
Key Cipher: CCMP (00:0f:ac) suite 04
MAC Address 10:C3:7B:54:74:D4
Key Index: 0 (0x00)
Interface Index: 13 (0x0000000d)
> Response: New Key (0x0b) len 4 [0x100]
1565892851.783032
Status: Success (0)
Here comes the REKEY_OFFLOAD which isn't supported:
< Request: Unknown (0x00) len 64 [ack]
1565892851.783051
> Response: Unknown (0x00) len 4
1565892851.783058
Status: Operation not supported (95)
< Request: Set Station (0x12) len 32 [ack]
1565892851.783075
Interface Index: 13 (0x0000000d)
MAC Address 10:C3:7B:54:74:D4
Station Flags 2: len 8
Mask: 0x00000002
Authorized
Set: 0x00000002
Authorized
> Response: Set Station (0x12) len 4 [root]
1565892851.783082
Status: Success (0)
> Event: Notify CQM (0x40) len 36
1565892852.026773
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
CQM: len 16
RSSI threshold event: 1 (0x00000001)
Reserved: len 4
c0 ff ff ff ....
And now AP is confused, because it never received our Handshake packet 4/4:
> Event: Control Port Frame (0x81) len 240
1565892852.757161
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
Wireless Device: 4294967299 (0x0000000100000003)
MAC Address 10:C3:7B:54:74:D4
Control Port Ethertype: 34958 (0x888e)
Frame: len 187
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 183
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: true
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: true
Key ACK: true
Key Length: 16
Key Replay Counter: 2
Key NONCE
e4 5b 1d 98 fd db 54 ae 54 98 fc 39 69 f5 bc 0b
.[....T.T..9i...
f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d de
....PC.m'.....m.
Key IV
f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d df
....PC.m'.....m.
Key RSC
83 01 00 00 00 00 00 00 ........
Key MIC Data
d1 16 8d c7 e6 ab 4d 6e 0a c6 0c 87 97 25 76 52
......Mn.....%vR
Key Data: len 88
78 d0 96 78 9f 2a 99 03 39 66 80 fd bd cf aa a5
x..x.*..9f......
6f 96 e2 bb 6b 95 51 e9 63 cd 69 17 7a 4a e2 f8
o...k.Q.c.i.zJ..
f6 b2 c4 f8 a0 08 8d b3 7d 1d ec d8 4a a1 60 33
........}...J.`3
e0 cb c0 14 26 d1 92 c4 70 91 6b ce a3 d2 11 5e
....&...p.k....^
99 90 65 22 49 e6 de 9f 01 02 e9 d4 53 37 2e 53
..e"I.......S7.S
6b f9 ab df d2 b4 8e 35 k......5
02 03 00 b7 02 13 ca 00 10 00 00 00 00 00 00 00 ................
02 e4 5b 1d 98 fd db 54 ae 54 98 fc 39 69 f5 bc ..[....T.T..9i..
0b f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d .....PC.m'.....m
de f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d .....PC.m'.....m
df 83 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 d1 16 8d c7 e6 ab 4d 6e 0a c6 0c 87 97 25 76 .......Mn.....%v
52 00 58 78 d0 96 78 9f 2a 99 03 39 66 80 fd bd R.Xx..x.*..9f...
cf aa a5 6f 96 e2 bb 6b 95 51 e9 63 cd 69 17 7a ...o...k.Q.c.i.z
4a e2 f8 f6 b2 c4 f8 a0 08 8d b3 7d 1d ec d8 4a J..........}...J
a1 60 33 e0 cb c0 14 26 d1 92 c4 70 91 6b ce a3 .`3....&...p.k..
d2 11 5e 99 90 65 22 49 e6 de 9f 01 02 e9 d4 53 ..^..e"I.......S
37 2e 53 6b f9 ab df d2 b4 8e 35 7.Sk......5
We reply
< Request: Control Port Frame (0x81) len 132 [ack]
1565892852.757715
Interface Index: 13 (0x0000000d)
Frame: len 99
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 95
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: false
Key Length: 0
Key Replay Counter: 2
Key NONCE
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
20 67 47 e4 d9 89 46 88 66 e1 bc a3 c7 74 37 87
gG...F.f....t7.
Key Data: len 0
02 03 00 5f 02 03 0a 00 00 00 00 00 00 00 00 00 ..._............
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 20 67 47 e4 d9 89 46 88 66 e1 bc a3 c7 74 37 . gG...F.f....t7
87 00 00 ...
Control Port Ethertype: 34958 (0x888e)
MAC Address 10:C3:7B:54:74:D4
> Response: Control Port Frame (0x81) len 4 [0x100]
1565892852.757735
Status: Success (0)
But it doesn't seems to receive that one either:
> Event: Control Port Frame (0x81) len 240
1565892853.748041
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
Wireless Device: 4294967299 (0x0000000100000003)
MAC Address 10:C3:7B:54:74:D4
Control Port Ethertype: 34958 (0x888e)
Frame: len 187
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 183
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: true
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: true
Key ACK: true
Key Length: 16
Key Replay Counter: 3
Key NONCE
e4 5b 1d 98 fd db 54 ae 54 98 fc 39 69 f5 bc 0b
.[....T.T..9i...
f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d de
....PC.m'.....m.
Key IV
f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d df
....PC.m'.....m.
Key RSC
84 01 00 00 00 00 00 00 ........
Key MIC Data
ac d8 64 f9 f3 77 64 78 b8 fe 13 3b d4 b9 b9 4c
..d..wdx...;...L
Key Data: len 88
78 d0 96 78 9f 2a 99 03 39 66 80 fd bd cf aa a5
x..x.*..9f......
6f 96 e2 bb 6b 95 51 e9 63 cd 69 17 7a 4a e2 f8
o...k.Q.c.i.zJ..
f6 b2 c4 f8 a0 08 8d b3 7d 1d ec d8 4a a1 60 33
........}...J.`3
e0 cb c0 14 26 d1 92 c4 70 91 6b ce a3 d2 11 5e
....&...p.k....^
99 90 65 22 49 e6 de 9f 01 02 e9 d4 53 37 2e 53
..e"I.......S7.S
6b f9 ab df d2 b4 8e 35 k......5
02 03 00 b7 02 13 ca 00 10 00 00 00 00 00 00 00 ................
03 e4 5b 1d 98 fd db 54 ae 54 98 fc 39 69 f5 bc ..[....T.T..9i..
0b f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d .....PC.m'.....m
de f6 a3 aa c5 50 43 9a 6d 27 e5 a4 bb e9 c5 6d .....PC.m'.....m
df 84 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 ac d8 64 f9 f3 77 64 78 b8 fe 13 3b d4 b9 b9 ...d..wdx...;...
4c 00 58 78 d0 96 78 9f 2a 99 03 39 66 80 fd bd L.Xx..x.*..9f...
cf aa a5 6f 96 e2 bb 6b 95 51 e9 63 cd 69 17 7a ...o...k.Q.c.i.z
4a e2 f8 f6 b2 c4 f8 a0 08 8d b3 7d 1d ec d8 4a J..........}...J
a1 60 33 e0 cb c0 14 26 d1 92 c4 70 91 6b ce a3 .`3....&...p.k..
d2 11 5e 99 90 65 22 49 e6 de 9f 01 02 e9 d4 53 ..^..e"I.......S
37 2e 53 6b f9 ab df d2 b4 8e 35 7.Sk......5
< Request: Control Port Frame (0x81) len 132 [ack]
1565892853.748627
Interface Index: 13 (0x0000000d)
Frame: len 99
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 95
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: false
Key Length: 0
Key Replay Counter: 3
Key NONCE
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
a7 ca 85 f4 a4 85 e8 9d 6b 0b 4e 73 c4 f4 58 cc
........k.Ns..X.
Key Data: len 0
02 03 00 5f 02 03 0a 00 00 00 00 00 00 00 00 00 ..._............
03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 a7 ca 85 f4 a4 85 e8 9d 6b 0b 4e 73 c4 f4 58 .........k.Ns..X
cc 00 00 ...
Control Port Ethertype: 34958 (0x888e)
MAC Address 10:C3:7B:54:74:D4
> Response: Control Port Frame (0x81) len 4 [0x100]
1565892853.748648
Status: Success (0)
So this cycle continues for a while until:
> Event: Unprot Deauthenticate (0x46) len 48
1565892859.690863
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
Frame: len 26
<snip>
> Event: Unprot Deauthenticate (0x46) len 48
1565892860.204587
Wiphy: 1 (0x00000001)
Interface Index: 13 (0x0000000d)
Frame: len 26
<snip>
Regards,
-Denis
^ permalink raw reply
* [RFC 1/1] RFC: allow mac address change on up iface
From: James Prestwood @ 2019-08-15 18:57 UTC (permalink / raw)
To: linux-wireless; +Cc: James Prestwood
In-Reply-To: <20190815185702.30937-1-prestwoj@gmail.com>
---
.../net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 ++
include/net/cfg80211.h | 1 +
include/uapi/linux/nl80211.h | 3 +++
net/mac80211/iface.c | 5 ++---
net/wireless/nl80211.c | 9 +++++++++
net/wireless/sme.c | 20 +++++++++++++++++++
6 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index fdbabca0280e..410daeb78208 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -601,6 +601,8 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_VHT_IBSS);
hw->wiphy->features |= NL80211_FEATURE_HT_IBSS;
+ wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_LIVE_ADDR_CHANGE);
+
hw->wiphy->regulatory_flags |= REGULATORY_ENABLE_RELAX_NO_IR;
if (iwl_mvm_is_lar_supported(mvm))
hw->wiphy->regulatory_flags |= REGULATORY_WIPHY_SELF_MANAGED;
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8fb5be3ca0ca..e067db9f61b9 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2433,6 +2433,7 @@ struct cfg80211_connect_params {
const u8 *fils_erp_rrk;
size_t fils_erp_rrk_len;
bool want_1x;
+ const u8 *random_mac;
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6f09d1500960..da7d770a6bf2 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2794,6 +2794,8 @@ enum nl80211_attrs {
NL80211_ATTR_STA_TX_POWER_SETTING,
NL80211_ATTR_STA_TX_POWER,
+ NL80211_ATTR_RANDOM_MAC_ADDR,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -5466,6 +5468,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_SCHED_SCAN_BAND_SPECIFIC_RSSI_THOLD,
NL80211_EXT_FEATURE_EXT_KEY_ID,
NL80211_EXT_FEATURE_STA_TX_PWR,
+ NL80211_EXT_FEATURE_LIVE_ADDR_CHANGE,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 06aac0aaae64..63d7b14189b0 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -205,9 +205,6 @@ static int ieee80211_change_mac(struct net_device *dev, void *addr)
bool check_dup = true;
int ret;
- if (ieee80211_sdata_running(sdata))
- return -EBUSY;
-
if (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
!(sdata->u.mntr.flags & MONITOR_FLAG_ACTIVE))
check_dup = false;
@@ -216,6 +213,8 @@ static int ieee80211_change_mac(struct net_device *dev, void *addr)
if (ret)
return ret;
+ dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+
ret = eth_mac_addr(dev, sa);
if (ret == 0)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 520d437aa8d1..bc975e49cd00 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -9887,6 +9887,15 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
connect.flags |= CONNECT_REQ_EXTERNAL_AUTH_SUPPORT;
}
+ if (info->attrs[NL80211_ATTR_RANDOM_MAC_ADDR]) {
+ if (!wiphy_ext_feature_isset(wiphy,
+ NL80211_EXT_FEATURE_LIVE_ADDR_CHANGE))
+ return -EINVAL;
+
+ connect.random_mac = nla_data(
+ info->attrs[NL80211_ATTR_RANDOM_MAC_ADDR]);
+ }
+
wdev_lock(dev->ieee80211_ptr);
err = cfg80211_connect(rdev, dev, &connect, connkeys,
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 7d34cb884840..8a09aad19752 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1218,6 +1218,26 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
wdev->conn_bss_type = connect->pbss ? IEEE80211_BSS_TYPE_PBSS :
IEEE80211_BSS_TYPE_ESS;
+ if (connect->random_mac) {
+ struct sockaddr *sa;
+ int len;
+
+ len = sizeof(sa_family_t) + max_t(size_t, dev->addr_len,
+ sizeof(*sa));
+ sa = kmalloc(len, GFP_KERNEL);
+ if (!sa)
+ return -ENOMEM;
+
+ sa->sa_family = dev->type;
+ memcpy(sa->sa_data, connect->random_mac,
+ dev->addr_len);
+
+ err = dev_set_mac_address(dev, sa, NULL);
+ kfree(sa);
+ if (err < 0)
+ return err;
+ }
+
if (!rdev->ops->connect)
err = cfg80211_sme_connect(wdev, connect, prev_bssid);
else
--
2.17.1
^ permalink raw reply related
* [RFC 0/1] Allow MAC change on up interface
From: James Prestwood @ 2019-08-15 18:57 UTC (permalink / raw)
To: linux-wireless; +Cc: James Prestwood
This is an example of how a devices MAC address could be changed while
the interface is up. Currently RTNL and mac80211 both require the
interface be down before changing the MAC.
After poking around a bit I found that some drivers can actually
change the MAC while the iface is up. Allowing user space to do this
while the iface is up would elminate a few potential race conditions
that arise when changing the MAC from user space.
This commit does a few things:
- Adds an EXT_FEATURE that user space can check to see if the driver
allows this MAC changing.
- Adds a new NL80211_ATTR for including a "random mac" to
CMD_CONNECT. This MAC is passed down the stack and gets set to
the net_device's address.
- Set this wiphy extended feature in iwlwifi (just as an example)
- Relax checks in mac80211 which check if the interface is running
- Set IFF_LIVE_ADDR_CHANGE on net_device. Note: I know setting this
where I did is likely not the right way to do it, but for this
proof-of-concept it works. With guidance I can move this around
to a proper place.
James Prestwood (1):
RFC: allow mac address change on up iface
.../net/wireless/intel/iwlwifi/mvm/mac80211.c | 2 ++
include/net/cfg80211.h | 1 +
include/uapi/linux/nl80211.h | 3 +++
net/mac80211/iface.c | 5 ++---
net/wireless/nl80211.c | 9 +++++++++
net/wireless/sme.c | 20 +++++++++++++++++++
6 files changed, 37 insertions(+), 3 deletions(-)
--
2.17.1
^ permalink raw reply
* Implementing Mikrotik IE
From: Josef Miegl @ 2019-08-15 15:28 UTC (permalink / raw)
To: linux-wireless
I've been trying to implement Mikrotik IE. It is a vendor IE that
carries stuff like radio name. Even though it is Mikrotik specific, UBNT
has a patch for madwifi:
https://github.com/jhairtt/ubnt-hal-0.7.379/blob/master/patches/madwifi-dfs-r3319-20080201/074-mtik-ie.patch
The IE is sent in beacon and assoc/reassoc frames. I think the correct
place for this is mac80211, but I'm not sure how should I expose a
switch to this functionality. Is there something like ioctl, or do I have
to implement a switch in nl80211, then in cfg80211 and then finally in
mac80211?
Any advice is greatly appreciated.
^ permalink raw reply
* Re: [PATCH] cfg80211: VLAN offload support for set_key and set_sta_vlan
From: Jeff Johnson @ 2019-08-15 15:23 UTC (permalink / raw)
To: Jouni Malinen
Cc: Johannes Berg, linux-wireless, Gurumoorthi Gnanasambandhan,
linux-wireless-owner
In-Reply-To: <20190815133825.8131-1-jouni@codeaurora.org>
On 2019-08-15 06:38, Jouni Malinen wrote:
> From: Gurumoorthi Gnanasambandhan <gguru@codeaurora.org>
> [...]
> By setting NL80211_EXT_FEATURE_VLAN_OFFLOAD flag the driver indicates
> support for a single netdev with VLAN tagged frames. Separate
> VLAN-specific netdevs are added using vcongig similar to Ethernet.
nit: s/vcongig/vconfig/
^ permalink raw reply
* [PATCH] cfg80211: VLAN offload support for set_key and set_sta_vlan
From: Jouni Malinen @ 2019-08-15 13:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Gurumoorthi Gnanasambandhan, Jouni Malinen
From: Gurumoorthi Gnanasambandhan <gguru@codeaurora.org>
This provides an alternative mechanism for AP VLAN support where a
single netdev is used with VLAN tagged frames instead of separate
netdevs for each VLAN without tagged frames from the WLAN driver.
By setting NL80211_EXT_FEATURE_VLAN_OFFLOAD flag the driver indicates
support for a single netdev with VLAN tagged frames. Separate
VLAN-specific netdevs are added using vcongig similar to Ethernet.
NL80211_CMD_NEW_KEY and NL80211_CMD_SET_STATION will optionally specify
vlan_id using NL80211_ATTR_VLAN_ID.
Signed-off-by: Gurumoorthi Gnanasambandhan <gguru@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
---
include/net/cfg80211.h | 4 ++++
include/uapi/linux/nl80211.h | 20 ++++++++++++++++++++
net/wireless/nl80211.c | 7 +++++++
3 files changed, 31 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 35ec1f0a2bf9..3355f56ca0b8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -509,6 +509,7 @@ struct vif_params {
* with the get_key() callback, must be in little endian,
* length given by @seq_len.
* @seq_len: length of @seq.
+ * @vlan_id: vlan_id for VLAN group key (if nonzero)
* @mode: key install mode (RX_TX, NO_TX or SET_TX)
*/
struct key_params {
@@ -516,6 +517,7 @@ struct key_params {
const u8 *seq;
int key_len;
int seq_len;
+ u16 vlan_id;
u32 cipher;
enum nl80211_key_mode mode;
};
@@ -1046,6 +1048,7 @@ struct sta_txpwr {
* (bitmask of BIT(%NL80211_STA_FLAG_...))
* @listen_interval: listen interval or -1 for no change
* @aid: AID or zero for no change
+ * @vlan_id: VLAN ID for station (if nonzero)
* @peer_aid: mesh peer AID or zero for no change
* @plink_action: plink action to take
* @plink_state: set the peer link state for a station
@@ -1081,6 +1084,7 @@ struct station_parameters {
u32 sta_modify_mask;
int listen_interval;
u16 aid;
+ u16 vlan_id;
u16 peer_aid;
u8 supported_rates_len;
u8 plink_action;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 822851d369ab..0af5740648e8 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -243,6 +243,17 @@
* %NL80211_ATTR_SAE_PASSWORD.
*/
+/**
+ * DOC: VLAN offload support for setting group keys and binding STAs to VLANs
+ *
+ * By setting @NL80211_EXT_FEATURE_VLAN_OFFLOAD flag drivers can indicate they
+ * support offloading VLAN functionality in a manner where the driver exposes a
+ * single netdev that used VLAN tagged frames and separate VLAN-specific netdevs
+ * can then be added using vconfig similarly to the Ethernet case.
+ * %NL80211_CMD_NEW_KEY and %NL80211_CMD_SET_STATION will optionally specify
+ * vlan_id using NL80211_ATTR_VLAN_ID.
+ */
+
/**
* enum nl80211_commands - supported nl80211 commands
*
@@ -2361,6 +2372,8 @@ enum nl80211_commands {
* @NL80211_ATTR_HE_OBSS_PD: nested attribute for OBSS Packet Detection
* functionality.
*
+ * @NL80211_ATTR_VLAN_ID: VLAN ID for the station and VLAN group key (u16).
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2820,6 +2833,8 @@ enum nl80211_attrs {
NL80211_ATTR_HE_OBSS_PD,
+ NL80211_ATTR_VLAN_ID,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -5452,6 +5467,10 @@ enum nl80211_feature_flags {
* @NL80211_EXT_FEATURE_SAE_OFFLOAD: Device wants to do SAE authentication in
* station mode (SAE password is passed as part of the connect command).
*
+ * @NL80211_EXT_FEATURE_VLAN_OFFLOAD: The driver supports a single netdev
+ * with VLAN tagged frames and separate VLAN-specific netdevs added using
+ * vconfig similarly to the Ethernet case.
+ *
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
*/
@@ -5497,6 +5516,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_EXT_KEY_ID,
NL80211_EXT_FEATURE_STA_TX_PWR,
NL80211_EXT_FEATURE_SAE_OFFLOAD,
+ NL80211_EXT_FEATURE_VLAN_OFFLOAD,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1a107f29016b..860aec59003a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -584,6 +584,7 @@ const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
.len = SAE_PASSWORD_MAX_LEN },
[NL80211_ATTR_TWT_RESPONDER] = { .type = NLA_FLAG },
[NL80211_ATTR_HE_OBSS_PD] = NLA_POLICY_NESTED(he_obss_pd_policy),
+ [NL80211_ATTR_VLAN_ID] = { .type = NLA_U16 },
};
/* policy for the key attributes */
@@ -3865,6 +3866,9 @@ static int nl80211_new_key(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_MAC])
mac_addr = nla_data(info->attrs[NL80211_ATTR_MAC]);
+ if (info->attrs[NL80211_ATTR_VLAN_ID])
+ key.p.vlan_id = nla_get_u16(info->attrs[NL80211_ATTR_VLAN_ID]);
+
if (key.type == -1) {
if (mac_addr)
key.type = NL80211_KEYTYPE_PAIRWISE;
@@ -5647,6 +5651,9 @@ static int nl80211_set_station(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_STA_AID])
params.aid = nla_get_u16(info->attrs[NL80211_ATTR_STA_AID]);
+ if (info->attrs[NL80211_ATTR_VLAN_ID])
+ params.vlan_id = nla_get_u16(info->attrs[NL80211_ATTR_VLAN_ID]);
+
if (info->attrs[NL80211_ATTR_STA_LISTEN_INTERVAL])
params.listen_interval =
nla_get_u16(info->attrs[NL80211_ATTR_STA_LISTEN_INTERVAL]);
--
2.20.1
^ permalink raw reply related
* backports-5.3-rc4-1, backports-5.2.8-1 and backports-4.19.66-1 released
From: Hauke Mehrtens @ 2019-08-15 13:16 UTC (permalink / raw)
To: backports; +Cc: linux-wireless
[-- Attachment #1.1: Type: text/plain, Size: 735 bytes --]
backports-5.3-rc4-1 was released. This is based on Linux 5.3-rc4.
https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.3-rc4/backports-5.3-rc4-1.tar.xz
backports-5.2.8-1 was released. This is based on Linux 5.2.8.
https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.2.8/backports-5.2.8-1.tar.xz
backports-4.19.66-1 was released. This is based on Linux 4.19.66.
https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v4.19.66/backports-4.19.66-1.tar.xz
There is now a updated wiki page with the releases:
https://backports.wiki.kernel.org/index.php/Releases
The source code can be found here:
https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/
Hauke
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/3] rtw88: update 8822c firmware files
From: Josh Boyer @ 2019-08-15 11:42 UTC (permalink / raw)
To: Tony Chuang
Cc: Linux Firmware, Linux Wireless, Larry Finger, Brian Norris,
Arend van Spriel
In-Reply-To: <1565252549-25524-1-git-send-email-yhchuang@realtek.com>
On Thu, Aug 8, 2019 at 4:22 AM <yhchuang@realtek.com> wrote:
>
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> Update 8822c firmware image, and add wowlan firmware.
> Also add a README to describe its usage.
>
> Yan-Hsuan Chuang (3):
> rtw88: RTL8822C: update rtw8822c_fw.bin to v7.3
> rtw88: RTL8822C: add WoW firmware v7.3
> rtw88: add a README file
>
> WHENCE | 1 +
> rtw88/README | 28 ++++++++++++++++++++++++++++
> rtw88/rtw8822c_fw.bin | Bin 184640 -> 189152 bytes
> rtw88/rtw8822c_wow_fw.bin | Bin 0 -> 138720 bytes
> 4 files changed, 29 insertions(+)
> create mode 100644 rtw88/README
> create mode 100755 rtw88/rtw8822c_wow_fw.bin
All three applied and pushed out. I edited the third patch to add the
README to WHENCE.
josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox