linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: "Rafał Miłecki" <rafal@milecki.pl>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
	"Kalle Valo" <kvalo@codeaurora.org>,
	"Franky Lin" <franky.lin@broadcom.com>,
	"Hante Meuleman" <hante.meuleman@broadcom.com>,
	"Chi-Hsien Lin" <chi-hsien.lin@cypress.com>,
	"Wright Feng" <wright.feng@cypress.com>,
	"Pieter-Paul Giesberts" <pieter-paul.giesberts@broadcom.com>,
	"Chung-Hsien Hsu" <stanley.hsu@cypress.com>,
	linux-wireless@vger.kernel.org,
	brcm80211-dev-list.pdl@broadcom.com,
	brcm80211-dev-list@cypress.com
Subject: Re: [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode
Date: Fri, 22 Jun 2018 20:59:35 +0200	[thread overview]
Message-ID: <5B2D4717.4000509@broadcom.com> (raw)
In-Reply-To: <779e159dc406dc16b004798756f6ee23@milecki.pl>

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

  reply	other threads:[~2018-06-22 18:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19 15:48 [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode Rafał Miłecki
2018-06-19 15:48 ` [PATCH V3 1/2] brcmfmac: detect firmware support for monitor interface Rafał Miłecki
2018-06-19 19:33   ` Arend van Spriel
2018-06-19 15:48 ` [PATCH V3 2/2] brcmfmac: handle monitor mode marked msgbuf packets Rafał Miłecki
2018-06-19 19:35   ` Arend van Spriel
2018-06-20  9:27   ` Dan Carpenter
2018-06-19 20:01 ` [PATCH V3 0/2] brcmfmac: initial work for adding monitor mode Arend van Spriel
2018-06-19 20:25   ` Rafał Miłecki
2018-06-22 18:59     ` Arend van Spriel [this message]
2018-06-24 14:20       ` Rafał Miłecki
2018-06-25  8:28         ` Arend van Spriel
2018-06-25  8:34           ` Rafał Miłecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5B2D4717.4000509@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=brcm80211-dev-list@cypress.com \
    --cc=chi-hsien.lin@cypress.com \
    --cc=franky.lin@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pieter-paul.giesberts@broadcom.com \
    --cc=rafal@milecki.pl \
    --cc=stanley.hsu@cypress.com \
    --cc=wright.feng@cypress.com \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).