[PATCH V3 0/2] brcmfmac: initial work for adding monitor mode

[PATCH V3 0/2] brcmfmac: initial work for adding monitor mode

[Rafał Miłecki]

From: Rafał Miłecki <rafal@milecki.pl>

After a bit long discussions in various e-mail threads I'm coming with
this simple & small patchset. It isn't complete support for monitor mode
but just a pair of preparing patches that should be clear & well
discussed by now to make them acceptable.

The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect
Arend to handle soon, as he already has a patch using "sta_monitor"
iovar for that. Then we have to discuss a flag for marking firmwares
which are capable for tagging monitor frames.

While still incomplete, I believe that with my previous patches, we can
agree this is a good direction.

Arend: if you find these 2 patches OK, could you ack them, to make it
clear for Kalle if they look OK now (or not yet)? I'd be great if you
could sent your "sta_monitor" work on top of this.

Rafał Miłecki (2):
  brcmfmac: detect firmware support for monitor interface
  brcmfmac: handle monitor mode marked msgbuf packets

 .../wireless/broadcom/brcm80211/brcmfmac/core.c    | 25 +++++++++++++++++++++
 .../wireless/broadcom/brcm80211/brcmfmac/core.h    |  2 ++
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 26 ++++++++++++++++++++++
 .../wireless/broadcom/brcm80211/brcmfmac/feature.h |  6 ++++-
 .../wireless/broadcom/brcm80211/brcmfmac/fwil.h    |  2 ++
 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c  | 17 ++++++++++++++
 6 files changed, 77 insertions(+), 1 deletion(-)

-- 
2.13.7

[PATCH V3 1/2] brcmfmac: detect firmware support for monitor interface

[Rafał Miłecki]

From: Rafał Miłecki <rafal@milecki.pl>

Most of firmwares support creating monitor interface. The newest ones
explicitly /announce/ it using a "monitor" entry in the list of
capabilities.

Check (and store) internally info about monitor mode support using a
new feature flag. Once we sort out all details of handling monitor
interface it will be used when reporting available interfaces to the
cfg80211.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V3: Patch added to the series
---
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 26 ++++++++++++++++++++++
 .../wireless/broadcom/brcm80211/brcmfmac/feature.h |  4 +++-
 .../wireless/broadcom/brcm80211/brcmfmac/fwil.h    |  2 ++
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index 800a423c7bc2..48d7978497b5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -48,6 +48,7 @@ static const struct brcmf_feat_fwcap brcmf_fwcap_map[] = {
 	{ BRCMF_FEAT_MBSS, "mbss" },
 	{ BRCMF_FEAT_MCHAN, "mchan" },
 	{ BRCMF_FEAT_P2P, "p2p" },
+	{ BRCMF_FEAT_MONITOR, "monitor" },
 };
 
 #ifdef DEBUG
@@ -91,6 +92,26 @@ static int brcmf_feat_debugfs_read(struct seq_file *seq, void *data)
 }
 #endif /* DEBUG */
 
+static void brcmf_feat_cmd_int_get(struct brcmf_if *ifp, enum brcmf_feat_id id,
+				   u32 cmd)
+{
+	u32 data;
+	int err;
+
+	ifp->fwil_fwerr = true;
+
+	err = brcmf_fil_cmd_int_get(ifp, cmd, &data);
+	if (err == 0) {
+		brcmf_dbg(INFO, "enabling feature: %s\n", brcmf_feat_names[id]);
+		ifp->drvr->feat_flags |= BIT(id);
+	} else {
+		brcmf_dbg(TRACE, "%s feature check failed: %d\n",
+			  brcmf_feat_names[id], err);
+	}
+
+	ifp->fwil_fwerr = false;
+}
+
 /**
  * brcmf_feat_iovar_int_get() - determine feature through iovar query.
  *
@@ -251,6 +272,11 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
 	}
 	brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_FWSUP, "sup_wpa");
 
+	/* Fallback detection for older firmwares */
+	if (!brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR))
+		brcmf_feat_cmd_int_get(ifp, BRCMF_FEAT_MONITOR,
+				       BRCMF_C_GET_MONITOR);
+
 	/* set chip related quirks */
 	switch (drvr->bus_if->chip) {
 	case BRCM_CC_43236_CHIP_ID:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
index d1193825e559..6eddb19ca48d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
@@ -33,6 +33,7 @@
  * MFP: 802.11w Management Frame Protection.
  * GSCAN: enhanced scan offload feature.
  * FWSUP: Firmware supplicant.
+ * MONITOR: monitor interface
  */
 #define BRCMF_FEAT_LIST \
 	BRCMF_FEAT_DEF(MBSS) \
@@ -48,7 +49,8 @@
 	BRCMF_FEAT_DEF(WOWL_ARP_ND) \
 	BRCMF_FEAT_DEF(MFP) \
 	BRCMF_FEAT_DEF(GSCAN) \
-	BRCMF_FEAT_DEF(FWSUP)
+	BRCMF_FEAT_DEF(FWSUP) \
+	BRCMF_FEAT_DEF(MONITOR)
 
 /*
  * Quirks:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
index 63b1287e2e6d..0d9492fd758d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h
@@ -60,6 +60,8 @@
 #define BRCMF_C_GET_PM				85
 #define BRCMF_C_SET_PM				86
 #define BRCMF_C_GET_REVINFO			98
+#define BRCMF_C_GET_MONITOR			107
+#define BRCMF_C_SET_MONITOR			108
 #define BRCMF_C_GET_CURR_RATESET		114
 #define BRCMF_C_GET_AP				117
 #define BRCMF_C_SET_AP				118
-- 
2.13.7

[PATCH V3 2/2] brcmfmac: handle monitor mode marked msgbuf packets

[Rafał Miłecki]

From: Rafał Miłecki <rafal@milecki.pl>

New Broadcom firmwares mark monitor mode packets using a newly defined
bit in the flags field. Use it to filter them out and pass to the
monitor interface. These defines were found in bcmmsgbuf.h from SDK.

As not every firmware generates radiotap header this commit introduces
BRCMF_FEAT_MONITOR_FMT_RADIOTAP flag. It has to be has based on firmware
capabilities. If not present brcmf_netif_mon_rx() will assume packet is
a raw 802.11 frame and will prepend it with an empty radiotap header.

This new code is limited to the msgbuf protocol at this point. Adding
support for SDIO/USB devices will require some extra work (possibly a
new firmware release).

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: Use cpu_to_le16 when setting it_len
V3: Update TODO comments
    Rename flag (after adding MONITOR)
    Update commit message
---
 .../wireless/broadcom/brcm80211/brcmfmac/core.c    | 25 ++++++++++++++++++++++
 .../wireless/broadcom/brcm80211/brcmfmac/core.h    |  2 ++
 .../wireless/broadcom/brcm80211/brcmfmac/feature.h |  4 +++-
 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c  | 17 +++++++++++++++
 4 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 72954fd6df3b..b1f702faff4f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -21,6 +21,7 @@
 #include <net/cfg80211.h>
 #include <net/rtnetlink.h>
 #include <net/addrconf.h>
+#include <net/ieee80211_radiotap.h>
 #include <net/ipv6.h>
 #include <brcmu_utils.h>
 #include <brcmu_wifi.h>
@@ -404,6 +405,30 @@ void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb)
 		netif_rx_ni(skb);
 }
 
+void brcmf_netif_mon_rx(struct brcmf_if *ifp, struct sk_buff *skb)
+{
+	if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MONITOR_FMT_RADIOTAP)) {
+		/* Do nothing */
+	} else {
+		struct ieee80211_radiotap_header *radiotap;
+
+		/* TODO: use RX status to fill some radiotap data */
+		radiotap = skb_push(skb, sizeof(*radiotap));
+		memset(radiotap, 0, sizeof(*radiotap));
+		radiotap->it_len = cpu_to_le16(sizeof(*radiotap));
+
+		/* TODO: 4 bytes with receive status? */
+		skb->len -= 4;
+	}
+
+	skb->dev = ifp->ndev;
+	skb_reset_mac_header(skb);
+	skb->pkt_type = PACKET_OTHERHOST;
+	skb->protocol = htons(ETH_P_802_2);
+
+	brcmf_netif_rx(ifp, skb);
+}
+
 static int brcmf_rx_hdrpull(struct brcmf_pub *drvr, struct sk_buff *skb,
 			    struct brcmf_if **ifp)
 {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index 401f50458686..dcf6e27cc16f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -121,6 +121,7 @@ struct brcmf_pub {
 
 	struct brcmf_if *iflist[BRCMF_MAX_IFS];
 	s32 if2bss[BRCMF_MAX_IFS];
+	struct brcmf_if *mon_if;
 
 	struct mutex proto_block;
 	unsigned char proto_buf[BRCMF_DCMD_MAXLEN];
@@ -216,6 +217,7 @@ void brcmf_txflowblock_if(struct brcmf_if *ifp,
 			  enum brcmf_netif_stop_reason reason, bool state);
 void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success);
 void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb);
+void brcmf_netif_mon_rx(struct brcmf_if *ifp, struct sk_buff *skb);
 void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
 int __init brcmf_core_init(void);
 void __exit brcmf_core_exit(void);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
index 6eddb19ca48d..0782f2aa3767 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.h
@@ -34,6 +34,7 @@
  * GSCAN: enhanced scan offload feature.
  * FWSUP: Firmware supplicant.
  * MONITOR: monitor interface
+ * MONITOR_FMT_RADIOTAP: monitor packets include radiotap header
  */
 #define BRCMF_FEAT_LIST \
 	BRCMF_FEAT_DEF(MBSS) \
@@ -50,7 +51,8 @@
 	BRCMF_FEAT_DEF(MFP) \
 	BRCMF_FEAT_DEF(GSCAN) \
 	BRCMF_FEAT_DEF(FWSUP) \
-	BRCMF_FEAT_DEF(MONITOR)
+	BRCMF_FEAT_DEF(MONITOR) \
+	BRCMF_FEAT_DEF(MONITOR_FMT_RADIOTAP)
 
 /*
  * Quirks:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index c40ba8855cd5..6abf9795930e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -69,6 +69,8 @@
 #define BRCMF_MSGBUF_MAX_EVENTBUF_POST		8
 
 #define BRCMF_MSGBUF_PKT_FLAGS_FRAME_802_3	0x01
+#define BRCMF_MSGBUF_PKT_FLAGS_FRAME_802_11	0x02
+#define BRCMF_MSGBUF_PKT_FLAGS_FRAME_MASK	0x07
 #define BRCMF_MSGBUF_PKT_FLAGS_PRIO_SHIFT	5
 
 #define BRCMF_MSGBUF_TX_FLUSH_CNT1		32
@@ -1128,6 +1130,7 @@ brcmf_msgbuf_process_rx_complete(struct brcmf_msgbuf *msgbuf, void *buf)
 	struct sk_buff *skb;
 	u16 data_offset;
 	u16 buflen;
+	u16 flags;
 	u32 idx;
 	struct brcmf_if *ifp;
 
@@ -1137,6 +1140,7 @@ brcmf_msgbuf_process_rx_complete(struct brcmf_msgbuf *msgbuf, void *buf)
 	data_offset = le16_to_cpu(rx_complete->data_offset);
 	buflen = le16_to_cpu(rx_complete->data_len);
 	idx = le32_to_cpu(rx_complete->msg.request_id);
+	flags = le16_to_cpu(rx_complete->flags);
 
 	skb = brcmf_msgbuf_get_pktid(msgbuf->drvr->bus_if->dev,
 				     msgbuf->rx_pktids, idx);
@@ -1150,6 +1154,19 @@ brcmf_msgbuf_process_rx_complete(struct brcmf_msgbuf *msgbuf, void *buf)
 
 	skb_trim(skb, buflen);
 
+	if ((flags & BRCMF_MSGBUF_PKT_FLAGS_FRAME_MASK) ==
+	    BRCMF_MSGBUF_PKT_FLAGS_FRAME_802_11) {
+		ifp = msgbuf->drvr->mon_if;
+
+		if (!ifp) {
+			brcmf_err("Received unexpected monitor pkt\n");
+			brcmu_pkt_buf_free_skb(skb);
+		}
+
+		brcmf_netif_mon_rx(ifp, skb);
+		return;
+	}
+
 	ifp = brcmf_get_ifp(msgbuf->drvr, rx_complete->msg.ifidx);
 	if (!ifp || !ifp->ndev) {
 		brcmf_err("Received pkt for invalid ifidx %d\n",
-- 
2.13.7

Re: [PATCH V3 1/2] brcmfmac: detect firmware support for monitor interface

[Arend van Spriel]

On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Most of firmwares support creating monitor interface. The newest ones
> explicitly /announce/ it using a "monitor" entry in the list of
> capabilities.
>
> Check (and store) internally info about monitor mode support using a
> new feature flag. Once we sort out all details of handling monitor
> interface it will be used when reporting available interfaces to the
> cfg80211.

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> V3: Patch added to the series
> ---
>   .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 26 ++++++++++++++++++++++
>   .../wireless/broadcom/brcm80211/brcmfmac/feature.h |  4 +++-
>   .../wireless/broadcom/brcm80211/brcmfmac/fwil.h    |  2 ++
>   3 files changed, 31 insertions(+), 1 deletion(-)

Re: [PATCH V3 2/2] brcmfmac: handle monitor mode marked msgbuf packets

[Arend van Spriel]

On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> New Broadcom firmwares mark monitor mode packets using a newly defined
> bit in the flags field. Use it to filter them out and pass to the
> monitor interface. These defines were found in bcmmsgbuf.h from SDK.
>
> As not every firmware generates radiotap header this commit introduces
> BRCMF_FEAT_MONITOR_FMT_RADIOTAP flag. It has to be has based on firmware
> capabilities. If not present brcmf_netif_mon_rx() will assume packet is
> a raw 802.11 frame and will prepend it with an empty radiotap header.
>
> This new code is limited to the msgbuf protocol at this point. Adding
> support for SDIO/USB devices will require some extra work (possibly a
> new firmware release).

Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> V2: Use cpu_to_le16 when setting it_len
> V3: Update TODO comments
>      Rename flag (after adding MONITOR)
>      Update commit message
> ---
>   .../wireless/broadcom/brcm80211/brcmfmac/core.c    | 25 ++++++++++++++++++++++
>   .../wireless/broadcom/brcm80211/brcmfmac/core.h    |  2 ++
>   .../wireless/broadcom/brcm80211/brcmfmac/feature.h |  4 +++-
>   .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c  | 17 +++++++++++++++
>   4 files changed, 47 insertions(+), 1 deletion(-)

Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode

[Arend van Spriel]

On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> After a bit long discussions in various e-mail threads I'm coming with
> this simple & small patchset. It isn't complete support for monitor mode
> but just a pair of preparing patches that should be clear & well
> discussed by now to make them acceptable.
>
> The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect
> Arend to handle soon, as he already has a patch using "sta_monitor"
> iovar for that. Then we have to discuss a flag for marking firmwares
> which are capable for tagging monitor frames.
>
> While still incomplete, I believe that with my previous patches, we can
> agree this is a good direction.
>
> Arend: if you find these 2 patches OK, could you ack them, to make it
> clear for Kalle if they look OK now (or not yet)? I'd be great if you
> could sent your "sta_monitor" work on top of this.

I acked them and I will submit my changes later. Either after these are 
applied or simply indicate the dependency.

Now as for where we are with this. With what we have here we know 
firmware can monitor packets with and without radiotap. However, we do 
not have an indication whether firmware can transport these monitor 
packets to the host. What I need to look into next is whether the 802.11 
flag in msgbuf is linked to a particular version of the protocol, but we 
may need to resort to the fwid table.

Regards,
Arend

Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode

[Rafał Miłecki]

On 2018-06-19 22:01, Arend van Spriel wrote:
> On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>> 
>> After a bit long discussions in various e-mail threads I'm coming with
>> this simple & small patchset. It isn't complete support for monitor 
>> mode
>> but just a pair of preparing patches that should be clear & well
>> discussed by now to make them acceptable.
>> 
>> The main missing bit is code setting MONITOR_FMT_RADIOTAP which I 
>> expect
>> Arend to handle soon, as he already has a patch using "sta_monitor"
>> iovar for that. Then we have to discuss a flag for marking firmwares
>> which are capable for tagging monitor frames.
>> 
>> While still incomplete, I believe that with my previous patches, we 
>> can
>> agree this is a good direction.
>> 
>> Arend: if you find these 2 patches OK, could you ack them, to make it
>> clear for Kalle if they look OK now (or not yet)? I'd be great if you
>> could sent your "sta_monitor" work on top of this.
> 
> I acked them and I will submit my changes later. Either after these
> are applied or simply indicate the dependency.
> 
> Now as for where we are with this. With what we have here we know
> firmware can monitor packets with and without radiotap. However, we do
> not have an indication whether firmware can transport these monitor
> packets to the host. What I need to look into next is whether the
> 802.11 flag in msgbuf is linked to a particular version of the
> protocol, but we may need to resort to the fwid table.

Being able to detect if firmware tags monitor packets would be great.

Please let us know if you find anything and thanks a lot for looking at
this patchset!

Re: [PATCH V3 2/2] brcmfmac: handle monitor mode marked msgbuf packets

[Dan Carpenter]

Hi Rafał,

I love your patch! Perhaps something to improve:

[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.18-rc1 next-20180619]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-detect-firmware-support-for-monitor-interface/20180620-012610
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master

smatch warnings:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c:1166 brcmf_msgbuf_process_rx_complete() error: we previously assumed 'ifp' could be null (see line 1161)

# https://github.com/0day-ci/linux/commit/71f840a490aca9a2d4e9609641a929c6936c20e2
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 71f840a490aca9a2d4e9609641a929c6936c20e2
vim +/ifp +1166 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c

9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1124  
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1125  
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1126  static void
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1127  brcmf_msgbuf_process_rx_complete(struct brcmf_msgbuf *msgbuf, void *buf)
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1128  {
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1129  	struct msgbuf_rx_complete *rx_complete;
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1130  	struct sk_buff *skb;
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1131  	u16 data_offset;
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1132  	u16 buflen;
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1133  	u16 flags;
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1134  	u32 idx;
c56caa9db drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-04-11  1135  	struct brcmf_if *ifp;
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1136  
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1137  	brcmf_msgbuf_update_rxbufpost_count(msgbuf, 1);
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1138  
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1139  	rx_complete = (struct msgbuf_rx_complete *)buf;
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1140  	data_offset = le16_to_cpu(rx_complete->data_offset);
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1141  	buflen = le16_to_cpu(rx_complete->data_len);
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1142  	idx = le32_to_cpu(rx_complete->msg.request_id);
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1143  	flags = le16_to_cpu(rx_complete->flags);
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1144  
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1145  	skb = brcmf_msgbuf_get_pktid(msgbuf->drvr->bus_if->dev,
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1146  				     msgbuf->rx_pktids, idx);
7d072b404 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Arend van Spriel 2015-05-26  1147  	if (!skb)
7d072b404 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Arend van Spriel 2015-05-26  1148  		return;
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1149  
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1150  	if (data_offset)
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1151  		skb_pull(skb, data_offset);
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1152  	else if (msgbuf->rx_dataoffset)
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1153  		skb_pull(skb, msgbuf->rx_dataoffset);
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1154  
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1155  	skb_trim(skb, buflen);
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1156  
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1157  	if ((flags & BRCMF_MSGBUF_PKT_FLAGS_FRAME_MASK) ==
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1158  	    BRCMF_MSGBUF_PKT_FLAGS_FRAME_802_11) {
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1159  		ifp = msgbuf->drvr->mon_if;
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1160  
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19 @1161  		if (!ifp) {
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1162  			brcmf_err("Received unexpected monitor pkt\n");
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1163  			brcmu_pkt_buf_free_skb(skb);
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1164  		}
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1165  
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19 @1166  		brcmf_netif_mon_rx(ifp, skb);
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1167  		return;
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1168  	}
71f840a49 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Rafał Miłecki    2018-06-19  1169  
c56caa9db drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-04-11  1170  	ifp = brcmf_get_ifp(msgbuf->drvr, rx_complete->msg.ifidx);
c56caa9db drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-04-11  1171  	if (!ifp || !ifp->ndev) {
c56caa9db drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-04-11  1172  		brcmf_err("Received pkt for invalid ifidx %d\n",
c56caa9db drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-04-11  1173  			  rx_complete->msg.ifidx);
c56caa9db drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-04-11  1174  		brcmu_pkt_buf_free_skb(skb);
c56caa9db drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-04-11  1175  		return;
c56caa9db drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-04-11  1176  	}
31143e293 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-06-02  1177  
31143e293 drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Franky Lin       2016-06-02  1178  	skb->protocol = eth_type_trans(skb, ifp->ndev);
9c349892c drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c Arend van Spriel 2016-04-11  1179  	brcmf_netif_rx(ifp, skb);
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1180  }
9a1bb6025 drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c          Hante Meuleman   2014-07-30  1181  

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode

[Arend van Spriel]

On 6/19/2018 10:25 PM, Rafał Miłecki wrote:
> On 2018-06-19 22:01, Arend van Spriel wrote:
>> On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> After a bit long discussions in various e-mail threads I'm coming with
>>> this simple & small patchset. It isn't complete support for monitor mode
>>> but just a pair of preparing patches that should be clear & well
>>> discussed by now to make them acceptable.
>>>
>>> The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect
>>> Arend to handle soon, as he already has a patch using "sta_monitor"
>>> iovar for that. Then we have to discuss a flag for marking firmwares
>>> which are capable for tagging monitor frames.
>>>
>>> While still incomplete, I believe that with my previous patches, we can
>>> agree this is a good direction.
>>>
>>> Arend: if you find these 2 patches OK, could you ack them, to make it
>>> clear for Kalle if they look OK now (or not yet)? I'd be great if you
>>> could sent your "sta_monitor" work on top of this.
>>
>> I acked them and I will submit my changes later. Either after these
>> are applied or simply indicate the dependency.
>>
>> Now as for where we are with this. With what we have here we know
>> firmware can monitor packets with and without radiotap. However, we do
>> not have an indication whether firmware can transport these monitor
>> packets to the host. What I need to look into next is whether the
>> 802.11 flag in msgbuf is linked to a particular version of the
>> protocol, but we may need to resort to the fwid table.
>
> Being able to detect if firmware tags monitor packets would be great.

The 802.11 tag as opposed the 802.3 tag is specified in the PCIe host 
interface spec. The brcmfmac driver support rev 5 and 6 of that spec and 
both specify the tags. I did some digging and I believe it is safe to 
say that firmware that includes the "monitor" tag in the "cap" iovar 
does support these packets tags as well. Unfortunately, the 
BRCMF_C_MONITOR command support does not guarantee. So I just sent a 
patch to remove the fall-back mechanism for detecting monitor mode support.

Regards,
Arend

Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode

[Rafał Miłecki]

On Fri, 22 Jun 2018 at 20:59, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 6/19/2018 10:25 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> > On 2018-06-19 22:01, Arend van Spriel wrote:
> >> On 6/19/2018 5:48 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
> >>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
> >>>
> >>> After a bit long discussions in various e-mail threads I'm coming wit=
h
> >>> this simple & small patchset. It isn't complete support for monitor m=
ode
> >>> but just a pair of preparing patches that should be clear & well
> >>> discussed by now to make them acceptable.
> >>>
> >>> The main missing bit is code setting MONITOR_FMT_RADIOTAP which I exp=
ect
> >>> Arend to handle soon, as he already has a patch using "sta_monitor"
> >>> iovar for that. Then we have to discuss a flag for marking firmwares
> >>> which are capable for tagging monitor frames.
> >>>
> >>> While still incomplete, I believe that with my previous patches, we c=
an
> >>> agree this is a good direction.
> >>>
> >>> Arend: if you find these 2 patches OK, could you ack them, to make it
> >>> clear for Kalle if they look OK now (or not yet)? I'd be great if you
> >>> could sent your "sta_monitor" work on top of this.
> >>
> >> I acked them and I will submit my changes later. Either after these
> >> are applied or simply indicate the dependency.
> >>
> >> Now as for where we are with this. With what we have here we know
> >> firmware can monitor packets with and without radiotap. However, we do
> >> not have an indication whether firmware can transport these monitor
> >> packets to the host. What I need to look into next is whether the
> >> 802.11 flag in msgbuf is linked to a particular version of the
> >> protocol, but we may need to resort to the fwid table.
> >
> > Being able to detect if firmware tags monitor packets would be great.
>
> The 802.11 tag as opposed the 802.3 tag is specified in the PCIe host
> interface spec. The brcmfmac driver support rev 5 and 6 of that spec and
> both specify the tags. I did some digging and I believe it is safe to
> say that firmware that includes the "monitor" tag in the "cap" iovar
> does support these packets tags as well.

OK, this is nice. The problem is we still need some fallback for the
old firmwares. Only the newest ones specify "monitor" tag in the "cap"
iovar. Older firmwares don't specify it but they still may include
support for monitor mode and radiotap header.

> Unfortunately, the
> BRCMF_C_MONITOR command support does not guarantee. So I just sent a
> patch to remove the fall-back mechanism for detecting monitor mode suppor=
t.

--
Rafa=C5=82

Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode

[Arend van Spriel]

On 6/24/2018 4:20 PM, Rafał Miłecki wrote:
> On Fri, 22 Jun 2018 at 20:59, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 6/19/2018 10:25 PM, Rafał Miłecki wrote:
>>> On 2018-06-19 22:01, Arend van Spriel wrote:
>>>> On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>
>>>>> After a bit long discussions in various e-mail threads I'm coming with
>>>>> this simple & small patchset. It isn't complete support for monitor mode
>>>>> but just a pair of preparing patches that should be clear & well
>>>>> discussed by now to make them acceptable.
>>>>>
>>>>> The main missing bit is code setting MONITOR_FMT_RADIOTAP which I expect
>>>>> Arend to handle soon, as he already has a patch using "sta_monitor"
>>>>> iovar for that. Then we have to discuss a flag for marking firmwares
>>>>> which are capable for tagging monitor frames.
>>>>>
>>>>> While still incomplete, I believe that with my previous patches, we can
>>>>> agree this is a good direction.
>>>>>
>>>>> Arend: if you find these 2 patches OK, could you ack them, to make it
>>>>> clear for Kalle if they look OK now (or not yet)? I'd be great if you
>>>>> could sent your "sta_monitor" work on top of this.
>>>>
>>>> I acked them and I will submit my changes later. Either after these
>>>> are applied or simply indicate the dependency.
>>>>
>>>> Now as for where we are with this. With what we have here we know
>>>> firmware can monitor packets with and without radiotap. However, we do
>>>> not have an indication whether firmware can transport these monitor
>>>> packets to the host. What I need to look into next is whether the
>>>> 802.11 flag in msgbuf is linked to a particular version of the
>>>> protocol, but we may need to resort to the fwid table.
>>>
>>> Being able to detect if firmware tags monitor packets would be great.
>>
>> The 802.11 tag as opposed the 802.3 tag is specified in the PCIe host
>> interface spec. The brcmfmac driver support rev 5 and 6 of that spec and
>> both specify the tags. I did some digging and I believe it is safe to
>> say that firmware that includes the "monitor" tag in the "cap" iovar
>> does support these packets tags as well.
>
> OK, this is nice. The problem is we still need some fallback for the
> old firmwares. Only the newest ones specify "monitor" tag in the "cap"
> iovar. Older firmwares don't specify it but they still may include
> support for monitor mode and radiotap header.

So in your list of firmwares, do you know (or can you find out :-p ) 
which ones return "monitor" and which do not? My educated guess was that 
only firmwares returning "monitor" tag have host-interface code in place 
to send monitor packets up to the host. You may prove me wrong.

Regards,
Arend

Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode

[Rafał Miłecki]

On 2018-06-25 10:28, Arend van Spriel wrote:
> On 6/24/2018 4:20 PM, Rafał Miłecki wrote:
>> On Fri, 22 Jun 2018 at 20:59, Arend van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 6/19/2018 10:25 PM, Rafał Miłecki wrote:
>>>> On 2018-06-19 22:01, Arend van Spriel wrote:
>>>>> On 6/19/2018 5:48 PM, Rafał Miłecki wrote:
>>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>> 
>>>>>> After a bit long discussions in various e-mail threads I'm coming 
>>>>>> with
>>>>>> this simple & small patchset. It isn't complete support for 
>>>>>> monitor mode
>>>>>> but just a pair of preparing patches that should be clear & well
>>>>>> discussed by now to make them acceptable.
>>>>>> 
>>>>>> The main missing bit is code setting MONITOR_FMT_RADIOTAP which I 
>>>>>> expect
>>>>>> Arend to handle soon, as he already has a patch using 
>>>>>> "sta_monitor"
>>>>>> iovar for that. Then we have to discuss a flag for marking 
>>>>>> firmwares
>>>>>> which are capable for tagging monitor frames.
>>>>>> 
>>>>>> While still incomplete, I believe that with my previous patches, 
>>>>>> we can
>>>>>> agree this is a good direction.
>>>>>> 
>>>>>> Arend: if you find these 2 patches OK, could you ack them, to make 
>>>>>> it
>>>>>> clear for Kalle if they look OK now (or not yet)? I'd be great if 
>>>>>> you
>>>>>> could sent your "sta_monitor" work on top of this.
>>>>> 
>>>>> I acked them and I will submit my changes later. Either after these
>>>>> are applied or simply indicate the dependency.
>>>>> 
>>>>> Now as for where we are with this. With what we have here we know
>>>>> firmware can monitor packets with and without radiotap. However, we 
>>>>> do
>>>>> not have an indication whether firmware can transport these monitor
>>>>> packets to the host. What I need to look into next is whether the
>>>>> 802.11 flag in msgbuf is linked to a particular version of the
>>>>> protocol, but we may need to resort to the fwid table.
>>>> 
>>>> Being able to detect if firmware tags monitor packets would be 
>>>> great.
>>> 
>>> The 802.11 tag as opposed the 802.3 tag is specified in the PCIe host
>>> interface spec. The brcmfmac driver support rev 5 and 6 of that spec 
>>> and
>>> both specify the tags. I did some digging and I believe it is safe to
>>> say that firmware that includes the "monitor" tag in the "cap" iovar
>>> does support these packets tags as well.
>> 
>> OK, this is nice. The problem is we still need some fallback for the
>> old firmwares. Only the newest ones specify "monitor" tag in the "cap"
>> iovar. Older firmwares don't specify it but they still may include
>> support for monitor mode and radiotap header.
> 
> So in your list of firmwares, do you know (or can you find out :-p )
> which ones return "monitor" and which do not? My educated guess was
> that only firmwares returning "monitor" tag have host-interface code
> in place to send monitor packets up to the host. You may prove me
> wrong.

None of my firmwares have "monitor" flag in the "cap" iovar. This seems
to be something really new. I'm still looking for some firmware new
enough to report "monitor" flag. Unfortunately most vendors seem to be
using 10.10.69.* or 10.10.122.20 which aren't new enough for that.